DeepSecurity 9.6SP1 CertProf Slides FINAL 28jan2016

Deep Security 9.
6 SP1
Certification Training for Professionals
Housekeeping
• Emergency Exits
• Washrooms
• Timetable
• Mobile Phones (Please set to vibrate)
• About Yourself
− Name, Company, Employee\Partner\Customer?
− Experience with Deep Security?
− Expectations for this Training?
• About Myself
2 Copyright 2016 Trend Micro Inc.

Course Objectives
• Describe the purpose, features, functions and capabilities of
Deep Security
• Explain Deep Security’s system architecture
• Review installation and deployment steps
• Identify protection modules and describe their functionality
• Determine available configuration and administration
options and requirements

Target Audience
• Individuals responsible for the Security and Protection
of Physical, Virtual, and Cloud Computing systems
– System Administrators
– Network Engineers
– Sales Engineers and Pre-Sales Engineers
– Technical Account Managers (TAMs)
– Support Engineers
– Integration Engineers
– Solution and Security Architects

Chapter 1: Product Overview
DEFINITIONS & TERMINOLOGY
PRODUCT FEATURES & MODULES
REQUIREMENTS
COMPONENTS COMMUNICATION

Key Functionality
• Security platform optimized for Servers and Desktops
Physical
Virtual
Cloud
Physical Virtual Cloud
Dedicated Server Desktop & Server Private, Hybrid &

Virtualization Public Cloud
Protection Modules - Introduction
6 Protection Modules

Firewall Module
• Helps reduce the attack surface
• Bi-directional and stateful Firewall
• Prevents Denial of Service (DoS) Attacks
• Detects and blocks Reconnaissance Scans

Intrusion Prevention Module
• Examines all incoming and outgoing traffic at
the packet level, searching for:
– Protocol deviations
– Policy violations
– Any content that signals an attack
• Detects and blocks known/unknown and
zero-day attacks that target vulnerabilities

Intrusion Prevention Module
• IPS can be used for:
Virtual Patching
– Drops traffic attempting to leverage unpatched vulnerabilities in
applications or the operating system. This keeps servers and
endpoints protected until relevant patches can be applied
Protocol Hygiene
– Block traffic based on how it conforms to protocol specifications;
Allows DSAs to detect packet fragments, packets without flags, and
similar anomalies
Application Control
– Block traffic associated with specific applications such as Skype, or
File-Sharing utilities
Web Reputation Module
• Web Reputation tracks credibility of websites and
safeguards users from malicious URLs
• Integrates with Trend Micro Smart Protection Network to

detect and block Web-based security risks, including
Phishing attacks
• Same behavior in both Agentless and Agent-Based DSAs

Anti-Malware Module
• Detects and blocks Viruses, Trojans, Spywares and
other Malware
• Based on VSAPI and SPN
• Real-Time, Scheduled or Manual

Agentless Anti-Malware
• Integrated with VMware vShield Endpoint APIs
– Agent software not installed on the protected virtual machine
• Virtual-Aware
– Automatically avoids AV storms which can occur if all Security
Applications on a given server simultaneously start to scan for
viruses or update pattern databases
• ESX Scanning De-Duplication
– Files scanned on VMs will be cached and shared across the
entire ESX/ESXi reducing access time and most importantly the
duration of On-Demand Scans
Log Inspection Module
• Collects and analyzes Operating System and Application
logs for suspicious behaviour, Security Events, and
Administrative Events across the datacenter
• Identifies relevant information buried in multiple Log
entries to assist with regulatory and compliance efforts
• Forwards events to SIEM system or Centralized Logging
Server for correlation, Reporting and Archiving
• Only available in Agent-Based

Integrity Monitoring Module
• Monitors critical operating system and application files, to
detect and report malicious and unexpected changes to:
– Directories
– Custom Files
– Registry Keys and Values
– Open Ports
– Processes and Services
• Reduces administrative overhead with Trusted Event Tagging
that automatically replicates actions for similar events across
the entire datacenter
Section 1.3: Components and
Architecture

Components and Architecture
Trend Micro Smart
Protection Network
Updates Web Reputation
File Reputation Feedback MSSQL/
Certified Safe Software ORACLE Administration (via Browser)
Public Cloud IaaS LDAP/AD

Managers Authentication and Discovery
Solo or Cluster (Optional)
VCloud EC2 Azure
VCenter
Virtual Appliance Support

(Optional)
Relays Smart Protection

Local Updates Servers Vshield
Dedicated or Local Web and File Manager
Co-located with Reputation Dedicated
Only (Optional) Virtual Appliance Support
Manager (Optional)
Virtual
Appliance
VM VM VM VM VM
Windows Linux Solaris HPUX/AIX Windows Linux

Server Server Server Server ESX
VM VM

Deep Security Manager
• Manages rules and settings for Agents, Relays and Virtual Appliances
• Integrates with different aspects of the datacenter including: VMware
vCenter/vCloud, AWS EC2, Microsoft Active Directory and has a web
services API (SOAP/REST) for integration with datacenter automation
environments
• Supports Windows and Linux Red Hat Operating Systems (only 64-bit)
• Requires a RDBMS (SQL/Oracle)
• Web Console based (Firefox 12+, Internet Explorer 8+, Chrome 20+,
Safari 5+)
• Multi-node for scalability

Deep Security Agent
• Provides endpoint protection for both physical and virtual
machines including:
– Anti-Malware
– Web Reputation
– Firewall
– Intrusion Prevention
– Integrity Monitoring
– Log Inspection
• Supports Windows, Linux, Solaris, HPUX, AIX

Deep Security Relay
• Deep Security Agent containing an Update Server
• Relays Security Updates from Trend Micro Global Active

Update Server to Deep Security networks that they
serve
• At least one DSR is always required for a DSM (can be

installed by default on DSM machine)

Deep Security Notifier
• Windows System Tray application that communicates the
state of the DSA and DSR to DSM
• Installed with DSA by default, can be installed for Agentless
• Provides end-user notifications of Anti-Malware actions
(Cleaned, Quarantined, Web Site blocked…) and console
utility
• Is available only for Windows (regardless of physical or
virtual machine)

Deep Security Virtual Appliance
• Transparently enforces security policies on VMware vSphere virtual
machines for Agentless protection
– Anti-Malware,
– Web Reputation
– Firewall
– Intrusion Prevention
• Runs as a VMware virtual machine and protects the other virtual
machines running on the same ESX Server
• Provides Agentless Recommendation Scan

Filter Driver
• ESXi kernel driver developed by Trend Micro
• Provides kernel level access to VM activities at the
hypervisor level for Agentless Firewall and Intrusion
Prevention modules
• Needs to be installed before the Deep Security Appliance
can be deployed (Preparation)
• Filter Driver 9.0 supports only ESXi 5.x
• Not required if using the NSX platform

Smart Protection Network
• Trend Micro Service that provides Real-Time
protection from emerging threats
• Continuously evaluating and correlating threat and
reputation intelligence for websites, email, and files
• Optional stand-alone Smart Protection Server can
be deployed locally
– Improves access time and increases privacy on behalf of
Anti-Malware and Web Reputation modules
Section 1.4 and 1.5: What’s New

What’s New DS 9.6 SP1
• Increased NSX Policy Integration
– To allow for NSX certification, Deep Security Manager can now be
configured to synchronize its policies with NSX
– vRealize Blueprints can be configured with either an NSX Security Group or
an NSX Security Policy that uses a Mapped Service Profile
• Multi-factor Authentication
– You can now enable multi-factor authentication when logging in to Deep
Security Manager
• Windows 10 Support
– The Deep Security Agent can protect computers that are running Microsoft
Windows 10
• Real-Time Anti-Malware Support for Amazon Linux
– Real-time Anti-Malware support is now available on Amazon
Linux
• Terms and Conditions

– Deep Security Manager can be configured to require users
to accept Terms and Conditions before logging in to the

• Report Classifications
– Reports feature has a new option that allows you to classify
and mark reports using:
• Top Secret, Secret, Confidential, For Official Use Only, Law Enforcement
Sensitive (LES), Limited Distribution, Unclassified, Internal Use Only
• Security Module Usage Cumulative Report

– A new “Security Module Usage Cumulative” report extends
the current Security Module Usage report
– Provides a cumulative total and the total in blocks of 100, of
the protection modules that were active over the course of a
specified timeframe
• Oracle RAC Support
– SUSE Linux Enterprise Server 11 SP3 with Oracle RAC 12c Release 1
– Red Hat Linux Enterprise Server 6.6 with Oracle RAC 12c Release 1
• Deep Security Agent Activation Secret

– Works like the activation secret for tenants
– If Agent Activation Secret is enabled, users will be required to
provide a shared secret in order to activate themselves

What’s new in DS 9.6
Deep Security 9.6 now supports vSphere 6
• NSX 6.1.4 Support and Integration:
– Agentless Anti-malware, Integrity Monitoring, Firewall and Intrusion
Prevention are available with NSX.
• vCNS 5.5.4 Support:
– Agentless Anti-malware and Integrity Monitoring are available for
vCNS.
– Combined Mode with Agentless Anti-malware and Integrity
Monitoring and Agent-based support for Firewall, Intrusion
Prevention and Web Reputation
SAP Protection For Linux
• The SAP adapter has been fully incorporated in to Deep Security 9.6
Agent as part of the Red Hat Enterprise Linux and SUSE Enterprise Linux
builds
• licensed directly through Deep Security Manager.
IBM QRadar Support

• Deep Security can now output Log Event Extended Format (LEEF 2.0) for
integration with IBM QRadar.

Real-Time Antimalware for CloudLinux
– Real-time anti-malware is available on CloudLinux 7.
Additional Platform Support

– Debian 6 and 7
– Windows 2012 Server Core
– CloudLinux 7
– Oracle Linux 7
– SUSE Enterprise Linux 12

Deep Security Database Support for Oracle 12c
– Deep Security Manager now supports Oracle 12c for its back-end
database.
Active Directory Synchronization on Login

– New users created in Active Directory can now log in to Deep
Security Manager before the Active Directory Synch task has been
run.

Deep Security Relay Update Downloads from Download Center
– In air-gapped situations, or situations where the Deep Security Relay cannot
directly access the Deep Security Manager, the Relay can now download
updates from Trend Micro Download Center.
Minor Report Enhancements

– The Security Module usage report now has columns for the Computer
Group and the Instance Size (for AWS workloads).
Automatic Updates of Online Help

– The Deep Security online help can now be updated seamlessly in Deep
Security Manager through a new Online Help package.

Chapter 2: Deep Security Manager

Section 2.1: Database

Database
• Database server is required by DSM
– Must be installed and created before installing Deep
Security Manager
• Can be installed on same or different System as
• Embedded (Derby) database ONLY suitable for
trial and demo purposes!

Database Requirements
• DSM operations can require high CPU and memory
resources
– Four cores and sufficient RAM for each DSM node
(recommended)
• Database should have specifications equal to or better
than the best DSM
• For optimal performance:
– Database should have 8-16 GB of RAM and fast access to the
local or network attached storage

Database Communication
• Important: DB and DSM co-located on same
network with a 1GB LAN connection
• A two millisecond (2 million nanoseconds)

latency or better is recommended

Database Communication

Encrypted Communication
• Communication between the Deep Security
Manager and the database is not encrypted by
default
• To encrypt, edit the dsm.properties file located in:
\Deep Security Manager\webclient\webapps\ROOT\WEB-INF\
NOTE: If you are running the Deep Security Manager in Multi-Node mode,
these changes must be made on each node

Running an Agent on the Database Server
• During a Security Update, the DSM stores new Intrusion
Prevention Rules in the database
• Rule names themselves will almost always generate false
positives as they get parsed by the Agent if the data is
not encrypted
– Encryption should be enabled between the database and the
DSM if you are using an Agent to protect the database
– Alternatively a Bypass rule can be created between the DSM and
the database host

Database Communication – Encryption
• MS SQL Server
– Add the following line to dsm.properties:
database.SqlServer.ssl=require
– Stop and restart the Deep Security Manager service
• Oracle Database
– Add the following lines to dsm.properties , for example:
database.Oracle.oracle.net.encryption_types_client=(AES256)
database.Oracle.oracle.net.encryption_client=REQUIRED
database.Oracle.oracle.net.crypto_checksum_types_client=(SHA1)
database.Oracle.oracle.net.crypto_checksum_client=REQUIRED
– Stop and restart the Deep Security Manager service
Dedicated Server
• DSM and the database can be installed on the
same computer if the deployment is not expected
to exceed 1000 computers (real or virtual)
• Over 1000 computers, the Deep Security Manager

and the database should be installed on
dedicated servers

Database Sizing
• With Logging at default levels, a protected computer
requires:
– 50 MB (on average) of database space for data
– Additional 5MB of space for transaction Logs
• To calculate the required disk space, multiply the

number of protected computers by 55 MB
– For example, 1000 computers will require 55 GB, 2000
computers will require about 110 GB, etc.

Database Sizing
• Space required per protected computer is a function of the
number of Events recorded and how long they are retained

Database Sizing
• TCP, UDP, and ICMP tabs on a Stateful Inspection Properties
window lets you configure how TCP stateful configuration
event logging is performed
• Similar settings are available for Firewall and Intrusion

Prevention Rules
Database Sizing
• Event collection settings should be fine-tuned at
the Global, Policy, and Host level
• Protection modules which generally consume the
most disk space (in descending order):
– Firewall
– Log Inspection

Database Preparation for Deep Security
• You must install the database software, create a database, and create a
User Account (which Deep Security Manager will use to access the
database) before you install Deep Security Manager
Account Details
• SQL Server Database creation:
– SQL Server account must be granted DB_Creator Server Roles and DB_Owner of the
Deep Security Manager database
• Oracle Database creation:

– Oracle Account must be assigned the Roles of CONNECT and RESOURCE and the
Account must be granted privileges to CREATE TABLES, CREATE SEQUENCES, and
CREATE TRIGGERS

Oracle RAC Support
• SUSE Linux Enterprise Server 11 SP3 with Oracle RAC 12c R 1
• Red Hat Linux Enterprise Server 6.6 with Oracle RAC 12c R 1
• Default Linux Server Deep Security policy requires new Firewall

settings if using Oracle RAC
– Default settings will not work with RAC environment due to complex
communication channels between RAC nodes
– Best Practise: Create a copy of the default Linux Server Deep Security policy
and customize the copy for use with Oracle RAC
Oracle RAC Required Firewall Settings
– Add a rule to allow the "interconnect" between each node
– Add a rule to allow the UDP port 42424
– Assign Oracle SQL Server rule (a pre-defined FW rule of Deep
Security)
– Set Network Engine Anti-Evasion Settings in DSM to "Normal"
(by default, this setting is set to "Strict" which would cause
the RAC database response to be extremely slow)

• When using named pipes to connect to an SQL Server, a
properly authenticated Microsoft Windows communication
channel must be available between DSM and the SQL Server
• This may already exist if:

– SQL Server is on the same host as DSM
– Both hosts are members of the same Domain
– Trust relationship exists between the DSM and SQL Server

Section 2.2: Deep Security Manager

Deep Security Manager (DSM) Components
• Tomcat - Web server and Application Server running Java
Server-side components 4119
Apache
4120
Tomcat
• Web Client - Responsible for generating the DSM Web
Console, and for implementing Access Control Web Client
Manager Embedded
• Manager Core - Java Windows/Linux libraries responsible Core Apache
Derby
for the main DSM functionality Jasper
Reports
Database
• Jasper Reports - Report generator running in Tomcat

• Embedded Derby (Optional) - Database installed for trial
and demo purposes
Default values for Apache/Tomcat communication ports are:
4119 Web-based Management Console and the static content download (VIB files,
Agent Installers)
4120 Heartbeat connections from the Deep Security Agents and Virtual Appliances
Accepting requests for distribution of Protection Policies and Security Settings
Ports

Ports
• On the Deep Security Manager
– Port 4120
• The "heartbeat" port, used by Deep Security Agents and DSVAs to communicate with Deep
Security Manager (configurable)
– Port 4119
• Used by Browser to connect to Deep Security Manager. Also used by install scripts to
retrieve the Core installer, and for communications from ESXi during DSVA Preparation and
Installation (configurable)
– Port 1521
• Bi-Directional Oracle Database Server port
– Ports 1433 and 1434
• Bi-Directional Microsoft SQL Server Database ports

Ports
• On the Deep Security Manager
– Ports 389, 636, and 3268
• Used for connection to an LDAP Server for Active Directory integration (configurable)
– Port 25
• For communications to an SMTP Server to send email alerts (configurable)
– Port 53
• Used for DNS Lookup
– Port 514
• Bi-Directional communications with a Syslog Server (configurable)
– Port 443
• For communications with VMware vCloud, vCenter, VShield Manager and Amazon
AWS

Ports
• On the Deep Security Relay, Agents and DSVAs
– Port 4122
• DSA/DSVA communications to Relay (updates)
– Port 4118
• Manager-to-Agent communications
– Port 80, 443
• Connection to Trend Micro Update Server and Smart Protection Server
– Port 514
• Bi-directional communications with a Syslog server (configurable)
NOTE: The Deep Security Manager automatically implements specific Firewall

Rules to open the required communication ports on machines hosting Deep
Security Relays, Agents and Appliances.
Network Communications
• Communications between Deep Security Manager
and Deep Security Relays/Agents/Appliances and
hypervisors uses DNS hostnames by default
• Ensure that each Computer can resolve the

hostname of the Deep Security Manager
NOTE: You will be asked for this hostname as part of the Deep Security
Manager installation. If you do not have DNS, enter an IP address.

Configuration Model
• DSM uses the following steps to obtain and
maintain all required configuration settings:
1. Load static settings, including the database connection settings
from a set of .properties configuration files
2. Load system-wide dynamic configuration settings from the
systemsettings database table
3. Load host-specific dynamic configuration settings from the
hostsystemsettings database table
4. Load other dynamic settings from other database tables

Configuration Files
• One per line, using the following format:
<name>=<value>
configuration.properties
• Created by the Installer in the Installation Directory and is not modified
after that
dsm.properties
• Contains the most relevant Deep Security Manager settings
• Includes the database type, connectivity details and authentication
credentials
• Deep Security Manager rewrites this file each time it starts
Configuration Files – dsm.properties
• Below are some parameters used to identify an SQL Server
database
Name of the database in the database server used
database.name <DB Name> by the Deep Security Manager, except for Oracle
Default is "dsm"
database.SqlServer.server <IP> | <Host> Name of the database server in the network
database. SqlServer.instance <String> Instance name, if different from default
database. SqlServer.user <String> User name in the database server
database. SqlServer.password <String> Encrypted user password in the database server

Configuration Files
override.properties
• Properties specified in this configuration file override properties
specified in the dsm.properties configuration file
• Can be created manually by a Support Engineer to change the product
behavior without affecting the original configuration
• Supports the same configuration settings as the dsm.properties
configuration file
logging.properties
• Controls the logging behavior for most of the Java code
DSM – High Availability
• Deep Security Manager can be run as multiple
nodes operating in parallel using a single
database
• Provides load balancing and failover capabilities
• Each DSM node is capable of all tasks
• No DSM node is more important than any of the
others

• Failure of any DSM node cannot lead to data loss or
incomplete/ failed tasks
• Network < 20,000; Agents/Appliances at least 2 DSM
nodes is advisable
• Network > 20,000; At least two nodes is recommended
Number of Nodes = Number of Devices / 40,000 + 1

• Each node must be running the same version

• First DSM to be upgraded will take over all DSM duties
• All other DSM nodes will appear as "offline"
• All critical DSM data stored in database
• Database Clustering supported in Oracle

and Microsoft SQL
• Oracle Data Guard and Microsoft SQL DB

Mirroring have no side effect

DSM – Load Balancing
• In a Multi-Node DSM environment all Agents and
Virtual Appliances have the address of all DSM
nodes
– Agents and Virtual Appliances use the list of addresses to
randomly select a DSM node to contact
– If busy, it will try the rest of the DSMs in the list until
none can be reached (or are all busy)

DSM – Load Balancers
• In Multi-Tenant environments, may need to add and
remove DSM nodes on-demand
– In this case, adding and removing DSMs would cause an update of
every Agent and Virtual Appliance in the environment
– To avoid this update, the Load Balancer setting can be used
• Load Balancers can be configured to use different ports for

the different types of traffic
– Or if the Load Balancer supports Port Re-direction, it can be used
to expose all of the required protocols over port 443 using three
Load Balancers


Enabling Detailed Logging on DSM
• Stop the Trend Micro Deep Security Manager Service
• Open the logging.properties file
– Windows:
...\Program Files\Trend Micro\Deep Security Manager\jre\lib\
– Linux:
/opt/dsm/jre/lib
• Add one or more of the debug options

• Save the changes and close the file
• Start the Trend Micro Deep Security Manager Service
• debug options:
– Option 1: UI Related Issues

• com.thirdbrigade.manager.webclient.screens.level=ALL
– Option 7: Database-related Issues
• com.thirdbrigade.persistence1.level = ALL
– Option 10: Agent Communication Protocol Logging
• com.thirdbrigade.manager.core.protocol.level = ALL
– Option 15: Active Update Issues
• com.thirdbrigade.manager.core.au.level=ALL

Setting Log Levels
• Log Levels that can be specified in logging.properties
– SEVERE (highest) Only message level indicating a serious failure
– WARNING Message level indicating a serious failure
– INFO Message level for informational messages
– CONFIG Message level for static configuration messages
– FINE Message level providing tracing information
– FINER Indicates a fairly detailed tracing message
– FINEST Indicates a highly detailed tracing

Installation – What You Will Need
• Deep Security Software Packages
– Download DSM Install Package from Trend Micro Download
Center (http://downloadcenter.trendmicro.com)
– Once DSM is installed, it can be used to download and
import Agent Packages directly
• DSM will then automatically download their updates
– Virtual Appliance, Notifier, and the Filter Driver Packages
must still be manually downloaded
– Imported Packages located in same folder automatically

Installation – What You Will Need
• License (Activation Codes)
– Deep Security Activation Codes required for the Protection Modules
– Separate Activation Code needed for Multi-Tenancy
– VMware Licenses will also be required for VMware components
• Administrator/Root Privileges
– Must have Administrator/Root privileges on Computers where Deep
Security Software components will be installed
• Reliable Time Stamps

– All Computers with Deep Security Software running should be
synchronized with reliable time source (NTP server)
System Requirements
• DSM must have Internet connectivity to download Software
Packages and Updates
• Deep Security Relay no longer a separate product in version 9.5 +
– DSR can be enabled on an installed and activated DSA
• Windows XP or Windows 2003 DSAs do not support IPv6
• On VMs protected by DSVA, the Anti-Malware module must be
licensed and enabled on the VM for the Deep Security Notifier to
display information
• Virtualized ESXi environment (Hypervisor running as VM) is not
supported

Install Deep Security Manager
• If installing DSM in a vCenter where you plan to

protect virtual machines, the DSM must not be
installed on the same ESXi as the VMs you are
planning to protect

Running Deep Security Manager
• Deep Security Manager service automatically
starts after Installation

DSM Console Access and Login
• You can access Deep Security Manager’s web
console:
– Locally on the DSM server
• Go to Start menu > Deep Security Manager
– From a remote computer
• Open a browser and connect to: https://[DSM host:[port]/
where,
[hostname] is the hostname of the DSM server
[port] is the "Manager Port" specified during the installation (4119 by default)

DSM Sign In Screen

Multi-Factor Authentication
• If MFA is enabled, in order to sign in to the DSM, you must provide:
– Your user name and password
– An authentication code from an MFA device
• Requires installation of MFA application

– Some supported combinations for your smartphone include:
• Android: Google Authenticator
• iPhone: Google Authenticator
• Blackberry: Google Authenticator
NOTE: Other MFA applications should work as well provided that they follow the
TOTP (time-based one time password) protocol.

Enabling MFA
• User Properties > General > Enable MFA

MFA Wizard

MFA Wizard On the device,
authentication code
for Deep Security
appears as follows:

MFA Wizard
• If device does not support scaning QR codes:

MFA Wizard
• From previous screen
paste in secret key

MFA Wizard
• Enter the Deep Security authentication code (without
spaces) from your MFA application

MFA Wizard
• If authorization code
entered is correct,
MFA is enabled

MFA Signing In

Disabling MFA
• If Admin is locked or loses phone
User Properties > General >
Disable MFA
• dsm_c -unlockout command can

also be used:
dsm_c -unlockout -username USERNAME [-newpassword NEWPASSWORD] [-disablemfa]

Terms and Conditions
• Can require users to accept Terms and Conditions before logging in to
DSM

Terms and Conditions – Sign In

Lab 1: DS Lab Environment
Lab 2: Installing Deep Security Manager

Chapter 3: Deep Security Agent

Deep Security Agent (DSA)
Deep Security Agent is the main I/O processing
component in Deep Security that implements all
protection technologies for the computers
Anti-Malware
Web Reputation AM functionality
Firewall
Intrusion Prevention HIPS functionality
Integrity Monitoring
Log Inspection HIDS functionality
Agent Architecture
• DSA consists of two main parts:
Agent Core (RPM/MSI) – Platform for communicating with
DSM as well as to download and install Plug-ins [+Notifier]
Features – Downloadable modules providing high-level

User-Visible Agent functionality
(For example, Log Inspection, Firewall, Anti-Malware)

Agent Architecture
• Initially only a Core Agent MSI/RPM/DEB is installed
• Smart Agent Policy driven Protection Module
installation
– All modules are now optional (previously only AM was
optional and decision was at initial install time)
– Only the Protection Modules assigned by Policy are installed
• Installed Protection Modules can be disabled but
cannot be uninstalled by Security Policy
– Since enabling/disabling a Protection Module could cause
repeated install/uninstall of driver modules
Agent Architecture

Agent Architecture
• To determine which Software Components must be
installed, Deep Security utilizes a three-tier architecture:
– Features: Logical Features that the Agent must implement depending on
the configured Protection Module (Firewall, Anti-Malware, etc.) or Agent
variants (Stand-Alone, Relay or DSVA)
– Plug-ins: Logical Components that may be shared by two or more
Protection Modules (For example, Firewall and Intrusion Prevention)
– Installed Components: Software Components and configuration changes
that are required to implement the selected Protection Modules or that are
associated with the specified Plug-ins

Agent Components

Agent Components
• dsa.exe – Main Agent process that communicates with the DSM and
Relay. It passes URLs on to TMUFE, monitors the Integrity Monitoring
Rules, and implements the Log Inspection Rules
• tbimdsa.sys – Network Driver that implements the Firewall, Stateful and
Intrusion Prevention scanning
• TMUFE – Trend Micro URL Filtering Engine, used for Web Reputation
• Notifier.exe (System) – Service that collects notification information
from other Agent components
• Notifier.exe (User) – Process that connects to the Service, retrieves the
Notification messages, and displays them to User in separate window

Agent Components

Anti-Malware Solutions Platform
• Deep Security Agent on Windows utilizes the Anti-Malware
Solutions Platform (AMSP) for Anti-Malware Protection
• AMSP components include:
– AMSP API - Libraries that allow the Trend Micro product to control the
AMSP components
– coreServiceShell.exe - AMSP service host process that loads all required
engines and starts the coreFrameworkHost.exe process
– coreFrameworkHost.exe - AMSP watchdog process that monitors the AMSP
host process status and can restart it if it is stopped
– VSAPI - Trend Micro Virus Scan Engine (vsapi.dll or vsapi64.dll) which scans
the intercepted data for Malware
Anti-Malware Solutions Platform (Engines)
• VSAPI - Trend Micro Virus Scan Engine
(vsapi.dll or vsapi64.dll)
• SSAPI - Anti-Spyware Engine and Patterns
• DCE - Damage Clean-up Engine and Patterns
• Whitelist - File Whitelisting Engine and Patterns

Protection Feature Installation States
• Visibility into the installation states of Protection
Modules
• Protection Module may be turned “On” in the
configuration, but until it is installed and providing
protection at the Agent, it is not actually "On"

Protection Feature Installation States
Installation State Description
On/Off Is the module really “On”? Agent is capable and module is “On” in configuration.
Installed Agent is reporting true for being capable of the module.

The module has been turned “On” in the configuration, but the Agent has not yet indicated
Installation Pending that installation has begun, completed, failed, nor that the Agent has become capable of the
module.
DSM has received an event from the Agent indicating that it has begun to install the module,
Installation In Progress
and has not yet received an event indicating success or failure of the installation.
Matching Module Plug-In not

No zip package imported at the DSM matches the version reported by the Agent.
Found
Not Supported/
Matching Agent zip is found, but it does not contain the given module.
Update Not Supported
The DSM has the module DSP for the Agent, but installation of the module has not been
Not Installed
initiated or is not in progress.

“dsa_control” Utility
• Initiate various maintenance tasks on a specific DSA
using the dsa_control control utility

Reset Deep Security Agent
• Reset action “-r”
– Cleans up all DSA configuration settings and DSA memory
– Removes relationship between DSA and DSM
– Removes corresponding entries from the database
• From a Command Prompt on the Agent, change to the DSA
folder and run the command dsa_control -r as follows:

Disable Agent Self Protection
• By default, if Anti-Malware functionality is installed, a DSA can protect its
Services, Installation Directories and Status from any modification, including
Shutdown
• To release Agent Self Protection , open a Command Prompt and enter
dsa_control --selfprotect=0 from the Agent installation directory:
• Once Agent Self Protection is disabled, ds_agent service can be controlled from
the Windows Services Manager

DSA Self Protection: Local Override Password

Section 3.2: Install Deep Security Agent

Install Deep Security Agent (Import)
• Importing Agent Software into DSM
1. In Deep Security Manager, go to Administration > Updates >

Software > Download Center. The Download Center page displays
the latest versions of all Agent software available from Trend Micro.
2. Select Agent software package from the list and click Import in the
menu bar. Deep Security will begin to download the software from
the Download Center, to the Deep Security Manager.
3. Once the software has been downloaded, a green check mark will
appear in the Imported column for that Agent.

4. The Local Software page lists the software that has already been
imported into Deep Security.
– “Is Latest” column shows if local software is up to date with software at
the Download Center
– “Import” button allows for the manual import of software from disk with
signature validation


Windows 10 Support
• Upgrade DSA to version 9.6 SP1 before
upgrading the operating system
• Windows 10 is not supported with Agentless
systems and combined mode

Install Deep Security Agent (Export)
• Exporting the Agent Software
– Once the import process is complete, Deep Security Agent software
can then be exported from DSM and saved to a local folder as either
a Package or Installer (.MSI)
– Steps to export the Agent install software from DSM:
1. In Deep Security Manager, go to Administration > Updates > Software
> Local.
2. Choose the Agent from the list and select Export > Export Installer...
For older versions of the Agent for the same platform, the latest
version of the software will have a green check mark in the Is Latest
column.
3. Save the Agent installer to a local folder.
Install Deep Security Agent (Export)

Install Deep Security Agent (Manually)
• Manually Installing the Agent Software
1. Copy the Agent Installer to the target machine and run the Installer
Package. At the Welcome screen, click Next to begin the installation.
2. End-User License Agreement: If you agree, select I accept the terms
of the license agreement and click Next.
3. Destination Folder: Select the path to install Deep Security Agent and
click Next.
4. Click Install to proceed with the installation.
5. Once the installation has completed, click Finish.
IMPORTANT: If upgrading a DSA host to Windows 10, the DSA must be upgraded
to version 9.6 SP1 before upgrading the operating system.
Install DSA Using Deployment Scripts

Install DSA Using Deployment Scripts
• Deployment Script Generator will generate a script which can be
imported into deployment tool that is being used
• Deployment scripts generated by DSM for Windows Agent
deployments require Windows Powershell version 2.0 or later
• To prevent the installation of entire Anti-Malware Engine, delete
the string "ADDLOCAL=ALL" from the Windows Deployment
Scripts (only for 9.0)
• To include Protection Modules during Installation of DSA 9.5 +:
– ADDDEFAULT=<dsa_features>

Silent Install
• msiexec.exe /q /i <DSA_Agent_Installer.msi>
ADDDEFAULT=<dsa_features>

Lab 3: Importing DSA Software
Lab 4: Deploying DSA

Section 3.3: Endpoint Management

Endpoint Management – Introduction
• Since DSM can only detect vulnerabilities and/or implement
security on endpoints listed in its hosts tree, adding
computers into DSM is a critical security task

Detection Method
• Identifying computers for Agent deployment
can be based on several methods:
– Hostname
– IP Address
– LDAP/X500 Directory
– VMware vCenter Server
– Cloud Account
Detection Method – Hostname
• Add a host using Wizard

Detection Method – IP Addresses
• Discovery based on IP addresses

Detection Method – LDAP
• Information from LDAP/X500 Directory

Filtering Active Directory Objects
• When importing Active Directory objects, search filters
are available to manage the objects that will be returned
• Should be used to enumerate physical computers
• Additional information about search filter syntax:
http://msdn.microsoft.com/en-us/library/aa746475(v=vs.85).aspx

• Computers are imported and synchronized
according to the structure in the Directory

Detection Method – vCentre
• Virtual machines in a VMware System

Detection Method – vCentre
• Similar to the LDAP connector, this connector
enumerates the VMs in the datacenter
• Real-time synchronization will be maintained

with this VMware vCenter to keep the
information displayed in the DSM up-to-date

Detection Method – Cloud
• Virtual machines in a VMware vCloud
Service, AWS EC2, or Microsoft Azure

Detection Method – Cloud
• Deep Security supports Agent-Based protection of
computing resources from following Cloud Providers:
– Amazon EC2
– VMware vCloud
– Microsoft Azure
• Once resources have been imported from Cloud Provider
Account into DSM, the computers in the account are
managed like any other computer on local network

Section 3.4: DSA Activation

Agent Activation
• Activation is required for the Agent / Relay / DSVA to start accepting
commands from the Deep Security Manager and report the status
• Activation includes the following steps:

– Transfer DSM SSL certificate and the URL to Agent (SetDSMCert command)
– Generate Global Unique Identifier (GUID) for Agent and transfer it to the
Agent (SetAgentCredentials command)
– Retrieve information about the Agent NICs (GetInterfaces command)
– Store information about registered Agent in Deep Security Manager
database (hosts and hostinterfaces tables)

Agent Activation – Management Console

Agent Activation – Command Line
• In addition to activation from the DSM console,
Administrators can also initiate Activation from the
DSA host using the Agent’s command line interface:
– dsa_control -a dsm://<host or IP>:<port>/
– dsa_control --activate dsm://<host or IP>:<port>/

Agent Activation – Script
• Script can automatically download Agent software from DSM, install DSA software,
or activate Agents

Agent Initiated Activation
• DSM must be set to accept Agent-Initiated Activation

Agent-Initiated Activation (AIA) Secrets
• Secure communication between DSA and the DSM in AIAs

Agent-Initiated Activation (AIA) Secrets
• If AIA is enabled and AIA secret is not provided
– Agents will be able to automatically activate
without providing authentication
• If AIA is enabled and AIA secret is provided
– Agents will be required to provide this secret value
in order to activate
• Sample script for Agent-Initiated Activation:
dsa_control -a dsm://dsm.training.local:4120/ "tenantPassword:secretvalue"

Automated Policy Activation
• Self-Activated DSAs can even be automatically assigned a
predetermined Security Policy to ensure at least a minimum
level of protection (using Event-Based Tasks)

Section 3.5: Deep Security Relay

Deep Security Relay
• Deep Security Relay (DSR) is responsible for retrieving Security Updates
and in some instances, Software Updates
• Updates are required for all Protection Module functionality (except
Firewall)
• Must have at least one DSR enabled in environment that is used for
Software Distribution as well as Pattern and Security Updates
• As of v9.5, Relay functionality is enabled by promoting a DSA Agent to a
DSR Agent (Agent maintains DSA functionality)
• Typical configuration is for the DSM to use a DSR co-located on the
same computer
• Deep Security Relays can be organized into hierarchical groups
Deep Security Relay – Architecture
• Deep Security Agent - Fully functional DSA Agent
• Deep Security Notifier - User notification service
reporting detected threats
• Relay Backend - Launches the Nginx Caching Proxy
Server and accepts forwarded commands coming
from DSM and DSVA
• Nginx Caching Proxy - Downloads updates, stores
them locally and offers to DSAs and DSVAs for
download
• By default, DSR uses the following TCP ports to accept connections:
4118 DSA accepting commands from the DSM
4122 Nginx accepting requests for updatable components from DSAs and DSVAs

Enable Deep Security Relay
– In the Deep Security Manager, go to the Computers screen
– Find the 64-bit Agent on which you want to enable Relay
functionality
– Go to Overview > Actions > Software and click Enable
Relay
NOTE: Only 64-bit DSA can be promoted to DSR

Lab 5: Protecting Endpoints

Section 3.6: Update Process

Deep Security Relay – Update Process

Update Process – Software Updates
• Latest DSA/DSVA packages hosted on the Trend Micro Download Center
• New packages are downloaded to DSM directly, either automatically or
initiated by an Administrator
• Relay Agent(s) request the packages from the DSM
– If the DSM is unavailable, the Relay Agent(s) may download the packages directly
from the Trend Micro Download Center
• DSR unpacks the packages and makes each Module Plug-in individually
available
• Agents (DSA\DSVA) will download the required components from a
Relay Agent and install them

Update Process – Security Updates
• When performing Security Updates, the DSM instructs the DSR to
download new Security Components from Trend Micro ActiveUpdate
Server
• Relay then performs the following tasks:
– Loads the list of required components from the DSM manifest file,
DS_Software_Manifest.xml
– Uses iActiveUpdate technology to update scan components in the Nginx
data directory, <AgentDir>/relay/iau
– Changes the Nginx configuration file to disable requests from the Agents
during updates
– Stops and re-starts the Relay Backend and the Nginx Caching Proxy Server

Update Process – Security Updates
Next step depends on the component type
– Anti-Malware & Web Reputation
• Agents retrieve the Anti-Malware and Web Reputation components (scan
components) from the DSR after receiving a command from the DSM
• Administrators can configure direct access to the ActiveUpdate Server as a
failover if the DSR goes offline
– Rules
• DSM downloads all rules from the DSR, stores them in the database and starts
transferring them to the Agents using the Policy Update command
– Policy Update
• When performing a Policy Update, the DSM transfers new policy configuration
and rules to the Agents and the Agents apply it to the computer
DSM Software Management
• Visibility into status of Agent Software
• Screens to view available content on Trend Micro Download
Center
• Automatic alerts when new Software becomes available

• Optional automatic download of new signed software and
Kernel Support packages
DSM Software Updates Overview

DSM Security Updates Overview

Deleting Imported Agent Packages
• Software packages cannot be deleted when in use
– Agent Installers in use if DSA deployed with same Platform/Version
– Kernel Support Packages depend on Agent Installers
– Kernel Support Packages are cumulative so only latest required
• Automatic database pruning removes all but top “N” packages

– Pruning done to manage disk space
– Packages is pruned from both DSM and DSR
– Will not delete “in use”, so “N” is minimum, not absolute
– Package pruning setting on DSM (Administration > System Setting > Storage >
Number of older software versions to keep per platform)
Update Bundles
• Transfer all available Security Components from one Relay to other Relay(s)
• Run "dsa_control -b" on the source Relay to create an Update bundle:
• Creates a ZIP-archive including all the content of the <InstallPath>/relay/iau

• Move created archive to DSR installation folder of destination system(s)

Update Source and Settings

Trend Micro Download Center Page
• Shows all software available from the Download Center

• Allows import of signed software
• “Imported” identifies software that has been imported into
DSM Local Software repository
• Software grouped by Platform and Version
DSM Local Software Page
• Shows software that has been imported into DSM

• Allows import of software from disk with signature
validation
• “Is Latest” shows if Local Software is up-to-date with
Software available from Download Center
Automatic Download: Signing DS Code Details
• Software Package Signature Verification
– Some (not all) software packages signed during loadbuild
– Signature verified by DSM (“cacerts” file + imported certs)
– Automatic import (from Download Center) – Signed packages only
– Manual import – Signature verification replaces fingerprint
– Manual import – Unsigned packages can be imported (SEG)
– Invalid signature always prevents import
– Signature does not expire
• Validation based on date signed, third-party timestamp service used to prevent spoofing
– Revocation by adding certificate serial number to hidden system setting
• Air gap and other issues prevent live CRL checking

Where to Obtain Core Agent Installer
• Agent Installer Extraction
– DSM Stores Agent Installer Package (.zip), containing:
• Installer (.msi, .rpm or .deb as appropriate to platform)
• Feature packages (.dsp)
– DSM serves full (.zip) packages to DSR for redistribution
– Full package (.zip) or installer (.msi/.rpm) can be extracted:

Viewing Computer Status
• Unmanaged Computer

• Computer with DSA

• Deep Security Relay

• ESX Server

• Virtual Appliance

• Virtual Machine

Chapter 4: Policies

Policies – Introduction
• Allow collections of rules and configuration
settings to be saved for easy assignment to
multiple computers
• Policies page displays existing policies showing

parent/child relationship in a hierarchical tree
structure

Policies
• Policy page used to:
– Create new policies
– Duplicate policies
– Import policies from XML files
– Export policies to XML or CSV file
– Delete policies
• Policy can be based on a Recommendation Scan
of Computer
Policies, Inheritance, and Overrides
• Policies page displays existing
policies showing parent/child
relationships
• Starts at parent Base Policy
level, and goes down multiple
levels of child policies ending
at Computer level where final
policy is assigned
Policies – Inheritance
• Child policies inherit settings from their parent
policies
– Allows you to create a policy tree that begins with a
parent Base Policy configured with settings and rules
that will apply to all Computers
• Parent policy can then have a set of child and
further descendant policies which can have
progressively more specific settings
Policies – Inheritance
• Anti-Malware setting in Policy is Inherited (Off)

Policies – Overrides
• Anti-Malware setting in Policy is Overridden (On)

Overriding Object Properties
• Properties of a particular rule can be changed using the
following options:
– Modify Properties(Global) to apply changes to ALL Instances where rule is
in use
– Modify Properties to only apply changes locally

Overriding Rule Assignment
• Additional rules can be assigned at any Policy or
Computer level
• Rules in effect at a particular Policy or Computer level

because their assignment is inherited from a parent
policy cannot be unassigned locally
• Properties of a particular rule can be modified globally or

locally

Policies – Overrides
• Overrides page in the Computer or Policy Editor displays
overridden settings

Rules Hierarchy

Rules Hierarchy
• Protection Settings from upper-level Policies can be
assigned or unassigned at the lower-level
Policies/Computer for Anti-Malware and Web Reputation
• Rules cannot be unassigned for the Firewall, Intrusion

Prevention, Integrity Monitoring and Log Inspection to
automatically apply changes in default Policies to all
affected endpoints

Rules Hierarchy
• Rule assigned at Policy level can be assigned
• Rule assigned at lower Policy level or Computer level,

inherited from higher Policy level cannot be unassigned

Rules Hierarchy
• By default, there is no policy assigned to a
Computer
• Administrators can configure individual protection
settings from scratch

Common Objects
• Common Objects pages list objects
that can be shared by many
constructs, such as policies and rules
• Root repository for shared objects

Common Objects
• Rules
– Used by various modules
• Lists
– Objects that can be reused by various configurations or rules by either
Policies or Computers
• Contexts
– Powerful way of implementing different security policies depending on the
Computer's network environment
– Helps protect against a network bridge configured between the wired and
wireless network, where you risk forwarding internal traffic externally
• Potentially expose internal hosts to external attacks

Common Objects
• Firewall Stateful Configurations
– Analyzes each packet in the context of Traffic History, correctness of TCP
and IP header values, and TCP connection state transitions
– With stateless protocols like UDP and ICMP, a pseudo-stateful mechanism is
implemented
• Malware Scan Configurations
– Detection settings and action for real-time or scheduled time
– If no scan configuration here, it cannot be selected and used by Policies or
Computers
– Every time a new configuration is created on a Policy or Computer, it will be
added in Common Objects as well

Common Objects
• Schedules
– Reusable timetables for configuring when certain actions should take place
• Tags
– Tags can be used to sort, group, and otherwise organize Events

Chapter 5: Anti-Malware

Anti-Malware
• Provides both Real-Time and On-Demand protection
against file-based threats, including threats commonly
referred to as Malware
• Checks files against a database
– Portions of which are hosted on Servers or kept locally as
updatable Patterns
• Anti-Malware also checks files for certain characteristics,
such as compression and known exploit code
NOTE: A newly installed Deep Security Agent cannot provide Anti-Malware protection
until it has contacted an Update Server to download Anti-Malware Patterns and Updates
Anti-Malware Solution Platform (AMSP)
• AMSP was designed to facilitate
integration of new technologies into
a product with minimal effort
• In an Agent installation, the AMSP
actually exists as a separate entity

AMSP Basics
• Core Framework
– Responsible for managing and using various Technology Plug-ins, and obtaining
Component Updates
– AMSP is a separate and distinct service from the DSA
• Technology Plug-ins
– Various Trend Micro Scan Engines (VSAPI, SSAPI, DCE), their Patterns, their
corresponding Drivers (for hooking into the OS), and associated Libraries that allow the
AMSP core framework to use them
• Client Library
– Products that use AMSP use a Client Library to interface with the AMSP core framework
Anti-Malware Scan Engines
• VSAPI – Virus Scanning API – Uses lpt$vpn or iCRC$oth + CRCZ.ptn
• SSAPI – Spyware Scanning API – Uses ssapiptn.da6
• DCE – Damage Cleanup Engine – Uses tsc.ptn
VSAPI detects and removes file-based components of malware
SSAPI and DCE address malware-related system alterations outside the

file system (for example, Malware processes in memory, Registry
entries, Layered Service Providers in the Protocol Stack, etc.)

Anti-Malware Scan Engines
• Scan Manager component responsible for making sure
these engines work together

Anti-Malware Scan Types



Quick & Full Scans

Quick & Full Scans

Scan Settings

Scan Settings

Scan Settings

Scan Settings

Scan Settings

Quarantine
• Designed to verify if file really was a malicious file
• For this to work, Administrators must receive notifications

when files are Quarantined
– Must have a means to access the Quarantined files
• Depending on results, the Administrator can then Restore

the file
– In the case of false positives

Quarantine - Restoration

Quarantine - Restoration

Quarantine – Restoration

Quarantine Disk Space
• Configure Maximum disk space used to store quarantined
files from Computer or Policy level in Anti-Malware
settings:
NOTE: If the limit is reached, the oldest files in Quarantine will be deleted
until 20% of allocated space is freed

Quarantine in DSA
• Quarantine files are compressed and
encrypted

Lab 6: Anti-Malware Protection

Section 5.5: Smart Protection

Smart Protection
• Trend Micro Smart Protection solution is a cloud-client content
security infrastructure that provides protection from security
risks and Web threats
• Shifts bulk of malware and spyware scanning functions to a

Smart Protection Server
• Keeps local pattern files small and reduces the size and number
of updates required by Agents/Appliances
• Can be accessed on the global Smart Protection Network or on a

Smart Protection Server installed locally

Smart Protection
• By default, settings for Smart Protection are:
– “Off” for DSVA
– “On” for DSA
• By default, Smart Protection Server for File Reputation Service is
Global Smart Protection Service

Smart Protection – How Does it Work?
Cyclic Redundancy Check (CRC)
• Two types of CRC information:

– Part 1: Used to identify potential Malware
– Part 2: Used to confirm if a file is Malware
NOTE: These “parts” can each consist of multiple data points

CRCs
VirusMeta
Part 1 Virus Part 2
(Jump Code) (main portion)
data File EOF Virus

CRCs
Virus part 1 Virus part 2

CRC part 1 File CRC part 2
(Jump code) (Main portion)
• Part 1 – Used for malware identification

• Part 2 – Used for malware confirmation
Conventional Pattern
• Contains both CRC Parts 1 & 2 Scan context
• Virus info Existing pattern
• Non-CRC data CRC Part 1

Scan
CRC Part 2
engine
Virus info
Non-CRC data

Smart Scan Pattern Smart filter generated based on
CRC Part 1 data
• Smart Query Filter New pattern External database

(Smart query filter) Existing pattern (Smart scan pattern)
– CRCZ.ptn CRC Part 1 CRC Part 1 CRC Part 1
• Smart Scan Pattern CRC Part 2 CRC Part 2
– iCRC.TBL Virus info Virus info
• Smart Scan Agent Pattern Non-CRC data
– iCRC$OTH
Non-CRC data
CRC & Virus info for

In-the-wild malware
Non-CRC pattern
(Smart scan agent pattern)

CRC – Analogy
Surname: Smith
First name: John
Telephone: 555-5555
Email: jsmith@mail.com
Mail: xyz corp
Occupation: Sales
Convictions: xxxxx
Charges: xxxxx
Photograph:

CRC – Analogy
Surname: Smith
First
Surname:
name: John
Smith
Telephone:
First
Surname:
name:555-5555
John
Smith
Email:
Telephone:
First
jsmith@mail.com
Surname:
name:555-5555
John
Smith
Mail:
Email:
Telephone:
xyzFirst
corp
jsmith@mail.com
Surname:
name:555-5555
John
Smith
Occupation:
Mail:
Email:
Telephone:
xyzFirst
corp
jsmith@mail.com
Surname:
Sales
name:555-5555
John
Smith
Convictions:
Occupation:
Mail:
Email:
Telephone:
xyz
First
xxxxx
corp
jsmith@mail.com
Surname:
Sales
name:555-5555
John
Smith
Charges:
Convictions:
Occupation:
Mail:
xxxxx
Email:
Telephone:
xyz
First
xxxxx
corp
jsmith@mail.com
Surname:
Sales
name:555-5555
John
Smith
Photograph:
Charges:
Convictions:
Occupation:
Mail:
xxxxx
Email:
Telephone:
xyz
First
xxxxx
corp
jsmith@mail.com
Surname:
Sales
name:555-5555
John
Smith
Photograph:
Charges:
Convictions:
Occupation:
Mail:
xxxxx
Email:
Telephone:
xyz
First
xxxxx
corp
jsmith@mail.com
Surname:
Sales
name:555-5555
John
Smith
Photograph:
Charges:
Convictions:
Occupation:
Mail:
xxxxx
Email:
Telephone:
xyz
First
xxxxx
corp Surname:
JohnSmith
jsmith@mail.com
Sales
name:555-5555
Photograph:
Charges:
Convictions:
Occupation:
Mail:
xxxxx
Email: First name:
Telephone:
xyzxxxxx
corp
jsmith@mail.com
Sales John
555-5555
Photograph:
Charges:
Convictions:
Occupation:
Mail:
xxxxx
Email: Telephone:
xyzxxxxx
corp 555-5555
jsmith@mail.com
Sales
Photograph:
Charges:
Convictions:
Occupation:
Mail:
xxxxxEmail:
xyzxxxxx
corpjsmith@mail.com
Sales
Photograph:
Charges: Mail:xxxxx
Convictions:
Occupation:
xxxxx xyz corp
Sales
Photograph:
Charges: Occupation:
xxxxx xxxxxSales
Convictions:
Photograph:
Charges:Convictions:
xxxxx xxxxx
Charges: xxxxx
Photograph:
Photograph:

Surname: Smith Surname: Jones
First name: John First name: Jack
Telephone: 555-5555 Telephone: 555-5556
CRC – Analogy
Email: Email: my@mail.com
jsmith@mail.com Mail: my address
Mail: xyz corp Occupation: Sales
Occupation: Sales Convictions: xxxxx
Surname: Sanchez xxxxx Surname: Costa xxxxx
Charges:
Convictions: First name: Jack
First name: John xxxxx
Charges: Photograph:
Photograph: Email: my@mail.com
Email:
Charges: xxxxx Surname: Lim
Convictions: Surname:
xxxxx Chua
Charges: xxxxx First name: John Photograph: First name: Jack
Telephone: 555-5556
Photograph: Telephone: 555-5555 Email: my@mail.com
Email:
Surname: Deveci xxxxx Surname: Sinkovitz
Charges: xxxxx
Convictions: First name: Jack
First name: Johnxxxxx
Charges: Photograph:
Email:
Surname: Chou Charges:Surname:
xxxxx Lee
Convictions: xxxxx First name: Jack
Charges: First name: John
xxxxx Photograph:
Email:
Surname: SmithCharges: xxxxx
Surnames only Surname: SmithConvictions: xxxxx
First name: JohnCharges: xxxxx First name: JackPhotograph:
Email:
Occupation: Sales
Smith Mail: xyz corp
Surname: Smith
Surname: Smith
Convictions: xxxxx Charges: xxxxx
Jones Charges: xxxxx First name: John Photograph: First name: Jack
Telephone: 555-5556
Photograph: Telephone: 555-5555 Email: my@mail.com
Sanchez Email:
Occupation: Sales
Mail: xyz corp
Chua Occupation: Sales
Surname: Deveci
Convictions: xxxxx
Surname: Chua
Convictions: xxxxx
Charges: xxxxx
First name:Charges:
Jen First name:Photograph:
Alp
Lim Telephone:Photograph:
555-5665
xxxxx Telephone: 555-6656
Email: alp@mail.com
Email: Jen@mail.com
Mail: my address
Deveci Mail: my address
Occupation: Sales Occupation: Sales
Convictions: xxxxx Convictions: xxxxx
Sinkovitz Charges: xxxxx Charges: xxxxx
Photograph:
Photograph:
Chou
Lee

CRC - Analogy
My name is
Walt Mott
Smith

CRC - Analogy
My name is All Details

John Smith for “Smith”
Smith
Surname: Smith
First name: John
Telephone: 555-5555
Email: mail@xyz.com
Mail: xyz corp
Occupation: sales
Convictions: xxxxx
Charges: xxxxx
Photograph:

CRC - Analogy
My name is All Details

John Smith for “Smith”
Smith
Surname: Smith
First name: John
Telephone: 555-5555
Email: mail@xyz.com
Mail: xyz corp
Occupation: sales
Convictions: xxxxx
Charges: xxxxx
Photograph:

CRC - Analogy
Confirmed !
How do I deal with
him ?
Smith
Surname: Smith
First name: John
Telephone: 555-5555
Email: mail@xyz.com
Mail: xyz corp
Occupation: sales
Convictions: xxxxx
Charges: xxxxx
Photograph:

CRC - Analogy
My name is Welcome
Denzel Smith on board
(No match)
Smith
Surname: Smith
First name: John
Telephone: 555-5555
Email: mail@xyz.com
Mail: xyz corp
Occupation: sales
Convictions: xxxxx
Charges: xxxxx
Photograph:

Smart Protection – How Does it Work ?
• Off

Smart Protection – How Does it Work ?
• On

Smart Protection Server
• Standalone Smart Protection Server
– CentOS-based virtual appliance that is available for
download from the Trend Micro Website
• Trend Micro Global Smart Protection Server

– Hosted by Trend Micro, accessible via the Internet

Chapter 6: Web Reputation

Web Reputation
• Web Reputation blocks access to malicious URLs
“ Approximately 10 billion URLs per day processed by Trend Micro
Web Reputation Services resulting in an average of 50,000
malicious URLs per day “ (2014)
• Web Reputation uses Trend Micro's Web Security databases
from Smart Protection Network sources
• Aggregated from multiple sources
– Web page links, domain and IP address relationships, spam sources,
and links in spam messages
• Web Reputation Security Level determines if DSM will block
or allow access to the URL
Web Reputation – Basics
• DSA/DSVA interfaces with the Ratings Servers using a
component called Trend Micro URL Filter Engine (TMUFE)

Credibility Scores
• Trend Micro crawls through websites and assigns
each site a score based on what it finds

Security Levels

Web Reputation – Ratings
• Security level can be:
– High: blocks pages that are: Dangerous, Highly
Suspicious, Suspicious
– Medium: blocks pages that are: Dangerous, Highly
Suspicious
– Low: blocks pages that are: Dangerous
– Block pages that have not been tested by Trend
Micro
Web Reputation – Exceptions
• Add site to the WRS exceptions list
Allowed
– Allow URLs from the
domain
– Allow the URL
Blocked
– Block URLs from the
domain
– Block the URL
– Block URLs containing
this keyword
Web Reputation – Score Evaluation
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

Web Reputation Operation

Web Reputation – Proxy

Web Reputation – Blocking Page

Web Reputation – Blocking Page
• Deep Security Notifier events are recorded in
Web Reputation Events tab

Web Reputation – Test Websites
Credibility Score URL

91 wrs91.winshipway.com

Web Reputation – False Positives
• Add site to
approved list

Web Reputation – False Positives
• Site Safety Center

– Report site to Trend Micro
global.sitesafety.trendmicro.com

Lab 7: Web Reputation

Chapter 7: Firewall

Firewall
• NDIS-based, bi-directional, stateful Firewall
• IPv6 is now supported by the Deep Security

Firewall and Intrusion Prevention modules

Firewall Operation – Rules
• Examine the control information in individual packets
• Either Block or Allow those packets
• Assigned directly to Computers or to Policies which
are in turn assigned to a host or collection of hosts
NOTE:
– Solaris Agents will only examine packets with an IP frame type
– Linux Agents will only examine packets with IP or ARP frame types
• Packets with other frame types will be allowed through
– Machines protected by DSVA do not have these restrictions

Firewall Rules
• Direction: Incoming, Outgoing
• Frame Types: IP, ARP, other…
• Transport Protocols: TCP, UDP, ICMP, etc.
• Packet Source and Packet Destination: IP address, MAC
address,Port
• TCP Header Flags: Can be used in different attacks
– For example, XMAS scan, RESET attack etc.

Firewall Rule Action
• Allow - Explicitly allows traffic that matches the rule to pass, and then
implicitly denies everything else
• Bypass - Allows traffic to bypass both Firewall and Intrusion Prevention
analysis
– For media-intensive protocols
– Only the port, direction, and protocol can be set with this action
• Deny - Explicitly blocks traffic that matches the rule
• Force Allow - Forcibly allows traffic that would otherwise be denied by
other rules
– Traffic permitted by a Force Allow rule will still be subject to analysis by
the Intrusion Prevention Module
• Log only - Traffic will be logged only (No other action will be taken)
More About the Allow Rule
• Permit traffic that is explicitly allowed
• Implicitly deny all other traffic
• Commonly applied Allow rules include:
– ARP: Permits incoming Address Resolution Protocol (ARP) traffic
– Allow solicited TCP/UDP replies: Ensures that the host computer is
able to receive replies to its own TCP and UDP messages
• Works in conjunction with TCP and UDP stateful configuration
– Allow solicited ICMP replies: Ensures that the host computer is able
to receive replies to its own ICMP messages
• Works in conjunction with ICMP stateful configuration

More About the Bypass Rule
• Designed for media-intensive protocols where filtering by the Firewall
or Intrusion Prevention modules is neither required nor desired
• Bypass rules have the following characteristics:
– Bypass skips both Firewall and Intrusion Prevention 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 created in pairs, one for incoming traffic and another for
outgoing
– Bypass rules will not be logged (not a configurable behavior)
– Some Bypass rules are optimized for maximum throughput

• Bypass rules can be used between a Deep Security Manager and a Deep
Security Agent running on a remote database server
• Deep Security Manager automatically implements a Priority 4 Bypass rule

that opens incoming TCP traffic at port 4118 on host computers running
Deep Security Agent
– Priority 4 ensures that this rule is applied before any Deny rule, and Bypass
guarantees that the traffic is never impaired
– This rule accepts traffic from any IP address and any MAC address (Create an
alternative, more restrictive, Bypass rule for this port to harden the DSA)

• Bypass Rule designed to allow matching traffic through at the fastest possible
rate. Maximum throughput can be achieved with (all) the following settings:
– Priority: Highest
– Frame Type: IP
– Protocol: TCP, UDP, or other IP protocol. (Do not use the "Any" option.)
– Source and Destination IP and MAC: all "Any"
– If the protocol is TCP or UDP and the traffic direction is "incoming", the Destination
Ports must be one or more specified ports (not "Any"), and the Source Ports must be
"Any"
– If the protocol is TCP or UDP and the traffic direction is "outgoing", the Source Ports
must be one or more specified ports (Not "Any"), and the Destination Ports must be
"Any"
– Schedule: None
More About the Force Allow Rule
• Excludes a subset of traffic that could otherwise have
been covered by a Deny action
• Traffic is still subject to Intrusion Prevention
• Useful for making sure that essential network

services are able to communicate with the DSA
computer
– For example, DHCP Client, Wireless Authentication

More About the Log Only Rule
• Log Only rules will only generate an Event if the
packet in question is not subsequently stopped by
either a Deny rule, or an Allow rule that excludes it
– If the packet is stopped by one of those two rules,
those rules will generate the Event and not the Log
Only rule
– If no subsequent rules stop the packet, the Log Only
rule will generate an Event

Firewall – Priorities

Firewall – How Rules work together
• Example of how the rules work together
Scope of traffic on
the network

Firewall – How Rules Work Together
• Allow rule will cause all other traffic not
specifically covered by the Allow rule to
be Denied

• A Deny rule can be implemented over
an Allow rule to Block specific types of
traffic

• Force Allow rule can be placed over the
denied traffic to allow certain exceptions to
pass through

Inline vs. Tap Mode

Inline vs. Tap Mode
Inline Mode Tap Mode
Traffic Traffic
Packet
analysis analysis
From From
network
Packet Application Packet Application
network

Order of Analysis
Platform-Dependent
Network Traffic
Driver Intercepts Traffic
Integrity Check
Check Blacklist
Check Firewall Rules
Stateful Configuration Check
SSL Inspection Decryption

(if decryption key available)
Check Intrusion Prevention Rules Application

Order of Analysis
• Integrity Check: Validity of packets (size, header condition)
• Blacklist: IP addresses that have been blacklisted
• Firewall: With the exception of the Bypass rule, which is
applied at the Microfilter, Firewall rules are applied at this
point

Order of Analysis – (cont’d)
• Stateful Configuration: Ensures that connection
behaves within pre-determined parameters thereby
protecting the DSA host from Denial of Service (DoS)
attacks
– Protocols supported: TCP, UDP, and ICMP
• SSL Inspection: If packet is part of an SSL connection,
the driver will decrypt the traffic to allow Intrusion
Prevention
– Certificates needed to permit decryption
Order of Analysis – (cont’d)
• Intrusion Prevention: 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

Firewall – Stateful Filtering
• Stateful Filtering plays a very important role in thwarting attacks
such as:
– Denial of Service (DoS)
– ACK Storm
• Traditionally, these attacks leverage the characteristics of stateful

protocols such as TCP
• Pseudo-stateful is implemented for stateless protocols such as:
– UDP
– ICMP

Firewall – Stateful Filtering
• After being explicitly allowed via static rules
• TCP connection state transitions
– Connection table
• Correctness of TCP and IP Header values
– Sequence numbers, flag combination etc.
• Works with stateless protocols (UDP, ICMP)
– Pseudo-stateful mechanism is implemented based on historical
traffic analysis
– By default, rejects any incoming UDP or ICMP request-reply and
error type packets
– Use Force Allow rules where needed

Firewall – TCP Stateful Configuration
• Of the three protocols that this feature supports, TCP is the
only protocol for which the Deep Security Administrator is
able to configure

Pseudo-Stateful Configuration – UDP/ICMP
Host A Host B
IP: 1.1.1.1 IP: 2.2.2.2
Host A accepts Src IP
1.1.1.1
Dst IP
2.2.2.2
Time stamp
00:00:00
UDP message
incoming UDP X seconds
message Src IP Dst IP Time stamp Response to UDP message
2.2.2.2 1.1.1.1 00:00:01
Host A Host B
Host A rejects IP: 1.1.1.1 IP: 2.2.2.2
incoming UDP ???? (No corresponding message)
message X seconds
Src IP Dst IP Time stamp UDP message
2.2.2.2 1.1.1.1 00:00:01
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.
Designing a Firewall Policy
• Prohibitive Policies
– If traffic is not expressly allowed, it is prohibited
– Can be created by using a combination of Allow rules to
describe allowed traffic and Deny rules to further restrict
permitted traffic
• Permissive Policies
– If traffic is not expressly prohibited, it is allowed
– Can be created through the exclusive use of Deny rules
to describe the traffic that should be dropped
Designing a Firewall Policy
• In general, prohibitive policies are preferred and
permissive policies should be avoided
• Force Allow rules should only be used in conjunction with

Allow and Deny rules to allow a subset of traffic that has
been prohibited by the Allow and Deny rules
• Force Allow rules are also required to allow unsolicited

ICMP and UDP traffic when ICMP and UDP stateful are
enabled
Firewall – Important Points
• Allow rules are prohibitive
– Anything not specified in the Allow rules is automatically
dropped
– This includes traffic of other frame types so you need to
remember to include rules
• If UDP stateful inspection is enabled a Force Allow rule

must be used to allow unsolicited UDP traffic
– For example, if UDP stateful is enabled on a DNS server then a
Force Allow for port 53 is required to allow the server to
accept incoming DNS requests

Firewall – Important Points
• If ICMP stateful inspection is enabled a Force Allow rule must be
used to allow unsolicited ICMP traffic
– For example, if you wish to allow outside ping requests a force allow
rule for ICMP type 3 (Echo Request) is required
• A force allow acts as a trump card only within the same priority
context
• If you do not have a DNS or WINS server configured, a Force
Allow incoming UDP port 137 rule may be required for NetBios
NOTE: When troubleshooting a new Firewall policy the first thing

you should do is check the Firewall rule logs on the Agent/Appliance.

Assessing Vulnerabilities

Assessing Vulnerabilities – Reconnaissance Scan
• Reconnaissance scans involve:
– Scanning packets
– Responses
– Absence of a response

• Network Mapping/Scanning
– Collecting a list of computers on a network that could then be
attacked
• Port Scanning
– Looking for open ports, betraying the presence of specific
applications and or vulnerabilities
• OS Fingerprinting
– Discovers the operating system of potential target machines
• Enumeration
– Causes the target to list, or enumerate, the resources that are
available on it, or its host network (user accounts, services, network
shares)

Assessing Vulnerabilities – Port Scanning
• Used to detect open, and potentially vulnerable, ports on
machines on company’s network
• Uses TCP packet with the SYN flag enabled

• DSM automatically adds its own IP address in the Ignore
Reconnaissance IP list of the Agent
• Uses by default port 1-1024 (can be changed in settings)
• Port scan results are displayed on the target Computer’s Details

screen


Lab 8: Firewall Rules

Chapter 8: Intrusion Prevention

Intrusion Prevention
• Protects against known/unknown and zero-day vulnerability
attacks
– Protects against SQL Injections, Cross-Site Scripting (XSS), and other
web application vulnerabilities
– Shields vulnerabilities until code fixes can be completed
• Various actions are then carried out on these packets

– Replacing specifically defined or suspicious byte sequences
– Completely dropping packets and resetting the connection

• Intrusion Prevention Rules examine the actual content of
the packet (and sequences of packets)
– Whereas Firewall Rules and Firewall Stateful Configurations
examine a packet's control information (data that describes the
packet)
DPI engine Rule match: Drop packet
DPI rule
Shellcode:do_something_bad
Reassembly Fragmentation
Network Packet:do_something_bad Application
process process

• Virtual Patching – Malicious instructions that leverage vulnerabilities on
unpatched machines can be intercepted before they reach the
vulnerability
Computer 1 (Attacker) Computer 2 (Victim)
Application
Malicious instruction:
Vulnerability
Do_Something_Bad
Protocol
stack
Protocol
DPI
stack

• Protocol Hygiene – Ensures that packet contents conform to pre-
determined security parameters (For example, absence of malicious
shellcode, URL length, etc.)
• Application Control – Can detect, or block traffic to specific

applications (For example, Skype logon attempts, etc.)
• Protecting Web Applications - This control can be used to block two

of the most common web site vulnerabilities; Cross-Site Scripting and
SQL Injection

Protecting Web Applications – Specific Vulnerabilities
• Cross-Site Scripting – A code injection attack that allows an

attacker to execute malicious script in another user's browser
• SQL Injection – An attack in which SQL code is inserted or

appended into application/user input parameters that are later
passed to a back-end SQL Server for parsing and execution

Protecting Web Applications – DPI Rules
Deep Packet Inspection module is able to defend against XSS and SQL
injection attacks through the following rules available out of the box as of
writing:
• 1000552 - Generic Cross-Site Scripting (XSS) prevention

• 1000608 - Generic SQL Injection prevention

Protecting Web Applications – DPI rules
• Administrators are able to
customize existing rules or add
their own custom Web
Application Protection rules

Protecting Web Applications – DPI rules
• Configuration options for
both XSS and SQL Injection
rules are very similar

Protecting Web Applications – Parameters in Detail
• 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:

• 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”

• Another pattern is designed to keep track of relevant scripting keywords

as below:

• As an example, we can apply both the previous patterns to the very simple
XSS attack reported below:
• 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 the script a total score of 11

• Drop Threshold – Defines the maximum score that a string can
accumulate before it is dropped

• 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

Intrusion Prevention – Prevent or Detect ?
• Behavior can be set to "Detect"
• Same Intrusion Prevention Rules will be applied to traffic but instead of
dropping packets, it will only log an Event and let the traffic pass

Intrusion Prevention – Prevent or Detect ?
• Used to ensure the new Intrusion Prevention Rules will
not interfere with legitimate traffic
• This setting only applies when the Network Engine is

operating Inline (live traffic is being streamed through the
Deep Security network engine)
– Prevent mode is impossible when in Tap mode because the
network engine does not control the live traffic stream

Intrusion Prevention – Types of Rules
• For any vulnerability, there can be multiple exploits
Exploit #1 for Vulnerability #1

Vulnerability
#1
• A rule that specifically protects against an exploit would be an exploit rule

• A vulnerability rule applies a virtual patch on the vulnerability protecting
against all exploits that use that vulnerability
• Smart rules are generic rules that provide virtual patching for one or several
vulnerabilities

Intrusion Prevention – Types of Rules
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

Intrusion Prevention – Rule Groups
• All – These rules are designed to defend against software vulnerabilities

and exploits. They mostly provide virtual patching functionality (but also
Web Application and Application Control rules)
• Web Application Protection – These rules are designed to protect
specifically Web applications from malicious attacks
• Application Control – As its name implies, these rules detect the use of
particular applications on the DSA host
Recommendation Scans
• Provides a snapshot of existing vulnerabilities on a host
• Provides list of rules that need to be applied to a computer
• Creates a guide for how to harden a host using Deep Security features
• Used by the Intrusion Prevention, Integrity Monitoring, and Log

Inspection modules

• Rules recommended as part of a Recommendation Scan can
be assigned to DSA in two ways:
– Direct to the DSA
– Via the Policy

• Recommendations for the DSA will be reflected on the assigned policy as well


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

• Recommended rules can be assigned

• Triggered by on-demand
• Can also be set to run as a scheduled task
• As a follow-up
SSL Filtering
– Filtering of SSL traffic is only supported by the Deep Security Agent, not the
Deep Security Appliance
– Agent does not support filtering SSL connections on which SSL compression
is implemented
– Settings only available on Computers, not Policies
SSL Compression
As Deep Security agent does not support filtering on SSL connections
with SSL compression enabled following can happen
• 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

SSL Basics
• HTTPS payload inspection must be able to observe the SSL
session establishment to be able to decrypt SSL traffic

DSA in an SSL connection
• Each time an SSL packet passes through a DSA the traffic is decrypted
and analyzed to incoming traffic and its corresponding response
Server
Client DSA Application
Decrypt
&
Analyze
Decrypt
&
Analyze

SSL Payload Inspection Packet deferred
DSA
Application
Step 1 Intended
destination
Deferred
Firewall
DPI / HTTPS Payload inspection

Step 2
Decryption Inspection Decision
Copy of
encrypted packet
Packet delivered
DSA
Application
Step 3
Lab 9: Intrusion Prevention
Lab 10: Application Control
Lab 11: Penetration Testing

Chapter 9: Integrity Monitoring

Integrity Monitoring – Operation
• Monitors selected system areas and alerts the Deep Security

administrator whenever a change occurs
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

Integrity Monitoring – Events
Windows Event Integrity Monitoring Event

Integrity Monitoring – Operation
• Works by comparing the current condition of a monitored
object with an existing baseline
Deep
Object Security
Agent
Compare
with
baseline
Baseline

Integrity Monitoring – Triggers
• The following events can trigger the comparison between a system
object and its baseline:
– On-demand scan trigger
– Real-time trigger
• Events are uploaded to the DSM as part of a heartbeat operation
• Events are forwarded in real-time via syslog to the SIEM or when the
next heartbeat communication (configurable) to the Deep Security
Manager occurs
NOTE: If free disk space drops below 5MB, Integrity Monitoring will be
suspended.
Integrity Monitoring – Display
• Events are displayed in the Integrity Monitoring Events
screen
− Files
− Folders
− Registry entries
− Processes
− Services
− Listening ports

Integrity Monitoring – Alerts
• Each Integrity Rule includes an Alert feature that is enabled
using the control shown below

Event Tagging
• Additional attribute that can be applied to Events of any
protection module and system events
• Used to sort, group, and organize Events
• Used to simplify the task of Event monitoring and
management
– Distinguish between Events that have been investigated and found
to be benign and those that require action
– Identify events that require further analysis
NOTE: Tags do not alter the data in the events in any way. They are simply extra
attributes attached to the event.
Event Tagging
• Manual Tagging
– Add one or more tags on an ad-hoc basis
– Can assign a tag used previously, or create a new tag
• Standard Auto-Tagging
– Can use an existing event as the model from which to create a rule
for auto-tagging similar Events on the same or other computers
• Trusted Source Auto-Tagging
– Can auto-tag events based on their similarity to known-good events
that occur on a Trusted Computer or found in the Certified Safe
Software Service, or in the Trusted Common Baseline
Event Tagging
• Auto-tagging Rule can also be configured to remove
existing tags
• Once an Auto-tagging Rule is created, it can be

assigned a Precedence value
• Precedence value determines the order in which

auto-tagging rules are applied to incoming events
– Values range from 1 (first) to 5 (last)

Auto Tagging Precedence Rules
User signed in
User signed in From now on, all future events where
User signed in aRemove
All
useruserssuspicious
signed
signed tag
thiswhere
in tagged
in and the not
as was
user
target
willuser
suspicious
me, showis– me – 1Rule 2 tag
aRule
suspicious
User signed in
User signed in
User signed in
User signed in
User signed in

Trusted-Source-Based Event Tagging
• In addition to auto-tagging similar events, the
Integrity Monitoring module allows you to tag
events based on their similarity to Events and data
found on Trusted Sources
– Local Trusted Computer
– Trend Micro Certified Safe Software Service
– Trusted Common Baseline

• Trusted Computer

• Trusted Computer
– Events compared with known trusted events from a
trusted computer, can be auto-tagged and filtered
• Before and after hashes compared
• Matches are automatically tagged as a trusted event
– Need trusted computer representative for each type of
computer
– Must apply same rule sets

• Certified Safe Software Service
– Whitelist of known-good file signatures maintained by
Trend Micro
– This type of Trusted-Source tagging will monitor target
computers for file-related Integrity Monitoring events
– When an event has been recorded, the file's signature
(after the change) is compared to Trend Micro's list of
known good file signatures
• If a match is found, the event is tagged
• Trusted Common Baseline method compares events within
a group of computers
• A group of computers is identified and a common baseline is
generated based on the Integrity Monitoring rules in effect
on the computers in the group
• When an Integrity Monitoring event occurs, the signature of
the file is compared to the common baseline
• If the file's new signature has a match elsewhere in the
common baseline, a tag is applied to the event
Lab 12: Integrity Monitoring

Chapter 10: Log Inspection

Log Inspection – Basics
• Identifies security events contained in log files on the DSA
host
• Suspicious events can be forwarded to a SIEM system or
centralized logging server
• Functions by implementing the open-source software
available at OSSEC.net
• Deep Security Manager collects Log Inspection Events from
the Deep Security Agents at every heartbeat

Event handling
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
...

• Events are stored in the database and displayed on the
Log Inspection Events screen as shown below

• Events will only be captured if their severity values exceed
Severity Clipping values

• If the Log Inspection rule was configured to send Alerts,
DSM will generate an alert for the log

Log Inspection – Operation
• DSA performs log inspection by reading the log files of
applications that it is instructed to inspect

Log Inspection – Events
Windows Event Log Inspection Event

Log Inspection – Log Parsing
Product /
DSA DSM
Log source
Create
alert
Yes
Database
Pre- Rule Database Is an alert
Event Decoding storage
decoding matching storage required?
(Local)
No
• Pre-decoding End
– DSA parses logs that contain pre-defined values

• Decoding
– Dynamic content is parsed
– Requires the use of decoders, which are created for each application
• Rule matching
– Once the log is parsed, it is compared to the rules that match the decoder and is
evaluated
Log Inspection – Log Parsing
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
• Database storage
– 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
• Alert
– This occurs on the DSM

Lab 13: Log Inspection

Chapter 11: Logs and Reports

Diagnostic Package –DSA
Using the DSM console
– Overview > Actions and select Create Diagnostic Package ...

Diagnostic Package
Agent Windows Manager
amgblcfg.xml AMSP\*.cfg Application- Running antimalware

Log.xml Processes events.csv
AMSP\*.bat .xml
amvmcfg.xml AMSP\*.log msinfo.nfo
antimalware
Windows\ quarantined
setupapi.app.log fileevents.csv
Security-
ds_agent iAU\
Log.xml
config.bin .config product.xml
Windows\ antimalware
System- setupapi.dev.log spyware
config.p7 ds_agent.db Log.xml events.csv
iAU\iAU.log
dpievents.csv
db_info.txt ds_agent.ini iAU\ dsa_mpnp
TmuDump.txt
firewallevents.
guids.txt csv
LogInspection\ LogInspection\ LogInspection\ hostevents.csv

LAconf.xml LAdecoders.xml LArules.xml
webreputation
Manager events.csv
Agent
configuration manager_ systeminformation dsa_ dsa_conn integrityevents
.pdf config<Id>.xml .xml blacklist.txt _track.txt .csv
security_ system. dsa_varia loginspectione

profile.xml host.xml builder.log dsa_stats.txt vents.csv
properties bles.txt

Diagnostic Package – DSA
• Using the command-line utility
– dsa_control -d
– ZIP file is created in the <AgentMainDir>/diag directory
– Diagnostic ZIP file includes the Agent configuration files, event
databases, system information and any intercepted traffic

Diagnostic Package – DSM
• Using the DSM console
– Administration > System Information
– Click Create Diagnostic Package…


• Using the command-line utility
dsm_c –action diagnostic
– <Install Dir> \diagnostic.zip

• Stop the Trend Micro Deep Security Manager service
• Open the logging.properties file under:
– For Windows: ..\Program Files\Trend Micro\Deep Security
Manager\jre\lib\
– For Linux: /opt/dsm/jre/lib
• Add one of more debugging parameters:
– com.thirdbrigade.manager.core.level=ALL
– com.thirdbrigade.manager.core.virtualization.vmware=ALL
• Save the changes and close the file
• Start the Trend Micro Deep Security Manager service
Enabling Detailed Logging on DSA
• Create a file named ds_agent.ini under the %SystemRoot%
directory (C:\Windows\ds_agent.ini)
• Add the following line to the file:

– Trace=Appl Beat Cmd Cfg Conn HTTP Log Lstn Srvc SSL
• Restart the Trend Micro Deep Security Agent service
• Similar for Linux, Solaris, HP-UNIX, AIX

Enabling Detailed Logging on DSA
You can use Debugview to view and save the Logs:
1. Download and run the DebugView utility DbgView.exe.
2. Replicate the issue.
3. Save an output of the log file.
NOTE: You can also save the log automatically by holding down the keys CTRL + G or by
clicking the Log to File icon. Locate a directory where you want to save the log, then click
OK.
4. Close the DbgView window.
NOTE: Enabling detailed logging of the Agent will generate more details on the diagnostic
package. Thus, it will generate larger and more files that may consume disk space.
5. Make sure to disable detailed logging once you have generated a diagnostic
package.
Enabling AMSP Debug Logging
• You can enable AMSP debug logs on DSA (9.5 +) through the
Agent trace file
• DSA saves log information to ds_agent.log file automatically
including (tracing and error/warning/information messages)
– Log file gets rotated automatically and is included in the Agent
diagnostic package
• Go to C:\Program Files\Trend Micro\Deep Security Agent
and execute the sendCommand that corresponds to the
action to use
Reports
• JasperReports open source reporting library
• A single report (one-off), or a recurring report can be

generated
• Existing reports cannot be edited and new ones cannot be

created
• If additional reports are required, please send a request to

Trend Micro Support
Reports
• Depending on which protection modules are used, these
reports may be available

Report Classifications
• Can assign optional classification to report

Report Filters
• Tag Filters • Computer Filters
– All Events – All Computers
– Untagged – My Computers
– Selected Tag(s) – In Group
• Time Filters – Using Policy
– Last 24 hours – Computer
– Last 7 Days • Encryption
– Previous Month – Disable Report Password
– Custom Range – Use Current User’s PW
– Use Custom Report PW
Recurring Reports
Most of the options are identical to those for single reports, with the exception of
Time Filter, which looks like this:
• Last [N] Hour(s): When [N] is less than 60, the start and end times will be at the top of the
specified hour. When [N] is more than 60, hourly data is not available for the beginning of
the time range, so the start time in the report will be changed to midnight (00:00) of the
start day.
• Last [N] Day(s): Includes data from midnight [N] days ago to midnight of the current day.
• Last [N] Week(s): Includes events from the last [N] weeks, starting and ending at midnight
(00:00).
• Last [N] Month(s): Includes events from the last [N] full calendar month, starting and
ending at midnight (00:00). For example, if you select "Last 1 Month(s)" on November 15,
you will receive a report for events that occurred between midnight October 1 to midnight
November 1.

Chapter 12: Multi-Tenancy

Multi-Tenancy – Purpose
• Allows you to create multiple distinct management
environments using a single Deep Security Manager and
database server installation
• Fully isolates the settings, Policies, and Events for each Tenant
• Provides segmentation for business units within an organization
and facilitate testing in staging environments prior to full
production deployments
• Allows the provision of Deep Security to customers within a
service model

Multi-Tenancy – Requirements
• Deep Security Manager 9 and higher
• Oracle Database or Microsoft SQL Server
• Database account privileges for database create/delete
operations
• Multi-Tenant Activation Code
• Optional but recommended:
– Multi-node Manager (more than one Deep Security Manager node
pointed to the same database for scalability)
– SMTP server
Multi-Tenancy – Primary Tenant (T0)
• Once installed, Deep Security Manager is the only Tenant
• After activating Multi- Tenancy, the initial Deep Security

Manager becomes the Primary Tenant (T0)
• Additional Tenants can be created but the Primary Tenant is

the only one that can manage and has control over the
other tenants
• Primary Tenant cannot be deleted

Multi-Tenancy – Installation Models
• Agent-Based Protection Models
– Single-Tenant Installation
– Multi-Tenancy Installation
• Agentless Protection Models
– Single-Tenant with VMware vCenter
– Multi-Tenancy Installation with VMware vCenter
– Multi-Tenancy Installation with VMware vCenter with Private Cloud
• Hybrid Protection Models
– Multi-Tenancy Installation in Hybrid Environment (VMware vCenter
with vCloud Private Cloud, Amazon and vCloud Public Clouds)
Agent-Based Protection Models
Single-Tenant Installation with Agent-Based Protection

Agent-Based Protection Models
• Multi-Tenancy installation with Agent-Based Protection

Agentless Protection Models
Single-Tenant Installation with VMware vCenter

Multi-Tenancy Installation with VMware vCenter

Multi-Tenancy Installation with VMware vCenter with
Private vCloud

Hybrid Protection Models
Multi-Tenancy Installation in Hybrid Environment
(VMware vCenter with vCloud private cloud, Amazon and
vCloud public clouds)

Multi-Tenancy – Database Architecture
• Multi-Tenancy in Deep Security Manager operates similarly
to a hypervisor
– Multiple Tenants exist within the same Deep Security Manager
installation but their data is highly isolated
• All DSM nodes process GUI, heartbeat or job requests for
any Tenant
• Majority of each Tenant's data stored in separate database
• Database may co-exist on the same database server as
other Tenants, or can be isolated onto its own database
server
Multi-Tenancy – Database

• When multiple database servers are available, Tenants are
created on the database server with least amount of load
• DSM decides which database server will host each Tenant’s
database
– This is not configurable by the Administrator
• Primary Tenant (T0) retains all of the capabilities of a
regular installation of Deep Security Manager
– However, subsequently created Tenants (TN) can have their access
to Deep Security functionality restricted

Single Tenant Multi-Tenant
Managed computers 100,000 1,000,000 or more
Deep Security
1-5 1-50
Manager Nodes
Databases 1 1-10,000
1
Database Servers (with or without 1-100
replication)

Multi-Tenancy – Enabling

Multi-Tenancy – License
• Inherit Licensing from Primary Tenant
– All Tenants use the same licenses (modules) as the Primary Tenant
– Recommended if using Multi-Tenancy for testing in a staging environment,
or to set up Tenancies for separate departments within the same
organization
• Per Tenant Licensing

– Provide license the moment that Tenant account is created (using the API)
or allow Tenants themselves to enter a license when logging in for the first
time
– Recommended when Deep Security is being offered as a service
Tenants

Creating Tenants
• Wizard used to create a new Tenant account
• If Tenant creation fails, verify the following:

– Does the database server account have sufficient permission?
– Can the database server support the creation of additional
databases (size or total number cap)?
– Check server0.log for errors

Managing Tenants
Created: In the progress of being created but not yet active

Confirmation Required: Created, but the activation link in the confirmation email sent to the
Tenant User has not yet been clicked. (You can manually override this state.)
Active: Fully online and managed
Suspended: No longer accepting sign ins
Pending Deletion: Tenants can be deleted, however the process is not immediate. (The Tenant
can be in the pending deletion state for up to seven days before the database is removed.)
Database Upgrade Failure: For Tenants that failed the upgrade path. (The Database Upgrade
button can be used to resolve this situation.)
Tenants Properties

Tenants Properties

Tenants Properties

Tenants Properties

Tenants Properties

Tenants Properties

Multi-Tenancy – Relay
• Each Deep Security Manager must have access to at least
one Deep Security Relay, and this includes the Tenants in a
Multi-Tenancy Deep Security installation
• By default, the Relays in the primary Tenant's Default Relay
Group are available to the other Tenants
• The setting is found in the primary Tenant's Deep Security
Manager in the Administration > System Settings >
Tenants > Multi-Tenant Options area
• If this option is disabled, Tenants will have to install and
manage their own Deep Security Relays
Multi-Tenancy – Upgrade
• Installer will detect existing installation
– Upgrade option offered
• If upgrade is selected the installer first informs other nodes to shut down and
then begins the process of upgrading
• Primary Tenant is upgraded first, followed by the Tenants in

parallel (five at a time)
• Once installation is complete, the same installer package
should be executed on any remaining Manager nodes

Multi-Tenancy – Diagnostic Packages
• Tenants are not permitted to access Deep Security
Manager diagnostic packages
– Due to sensitivity of the data
• Tenants can still generate Agent diagnostics by
opening the Computer Editor and selecting Agent
Diagnostics from the Actions tab on Overview page

Multi-Tenancy – Agent Activation
• Agent-initiated activation is enabled by default for
all Tenants
• Unlike Agent-initiated activation for the Primary
Tenant, a password and Tenant ID are required to
invoke the activation for Tenant Users
dsa_control -a dsm://manageraddress:4120/
"tenantID:7156CF5A- D130-29F4-5FE1-8AFD12E0EC02"
"tenantPassword:98785384-3966-B729-1418-
3E2A7197D0D5"
Multi-Tenancy – Agent Activation

Multi-Tenancy – Tenant Usage Monitoring
• Primary Tenant records data about Tenant usage
– Tenant Protection Activity widget on the Dashboard
– Tenant Properties window's Statistics tab
– Chargeback report
– Status Monitoring REST API
• Administration > System Settings > Advanced > Status Monitoring API
• Can be customized to determine what attributes are included in
the record
• Designed to accommodate various charging models that may be
required in service provider environments
• For enterprises, this may be useful to determine the usage by
each business unit
Multi-Tenancy – Usage Monitoring

Multi-Tenancy – Supporting Tenants
• Sign in as Tenant grants immediate access
• Users are logged in as a special account on the Tenant
• User is deleted when the support user times out or
signs out of the account
• Tenant can view all actions under System Events
– For example, user account creation, sign in, sign out,
account deletion etc.
• Users in the Primary Tenant also have additional
diagnostic tools available to them

Multi-Tenancy – User View
• Tenants are required to enter their Account Name in addition to their
Username and Password
• Some features in the UI are not available to Tenant Users
• Tenants cannot see any of the Multi-Tenant features of the Primary
Tenant or any data from any other Tenant
• Certain APIs are restricted since they are only usable with Primary
Tenant rights (such as creating other Tenants)
• All Tenants have the ability to use Role-Based Access Control with
multiple user accounts to further sub- divide access
• Tenants can use Active Directory/vCenter/vCloud integration

Multi-Tenancy – Web API
• Deep Security Manager includes REST API for these functions:
– Managing Cloud Connectors
– Managing Tenants and Templates
– Managing Secondary Database Servers
– Monitoring/Chargeback API (DB Size, Tenant Usage, Protection Hours, etc.)
– Status API (Advanced “ping” service; Unauthenticated)
• SOAP API is still available (client applications can use one or both
simultaneously)
• Additional information about REST API can be requested from Support

Lab 14: Multi-Tenancy

Chapter 13: Agentless Protection

Deep Security Virtual Appliance (DSVA)
• Provides protection of virtual machines (VMs) in a VMware
vSphere environment without requiring an in-guest Deep
Security Agent
• Virtual machines are managed as if they had an Agent
installed
• DSVA is part of the DSA architecture and is a guest VM
running 64-bit CentOS
• Smart policy driven install does not make sense for DSVA
– All relevant plugins are installed and updated automatically
Deep Security Virtual Appliance (DSVA)
• DSVA software upgrade is performed same as DSA upgrade --- not by
image upgrade
– With NSX the DSVA OVF is deployed and managed by vCenter/NSX and not by DSM
• DSVA platform/OS security updates via patch/rpm in the VMware

plugin
– For example, vmware-tools is easier to update without reimage
• DSVA platform is CentOS6

– No upgrade from 9.0 DSVA
– DSVA console functionality stripped due to NSX management of DSVA

DSVA - Security Advantages
• Appliance is isolated from the guest
• Short-lived and reverted machines can easily and quickly be
protected
• VMs whose operating systems are not directly accessible can be
protected, even those hosts being managed by other
Administrators
• Deep Security Virtual Appliance is easier to deploy
• No need to remotely install Agent software on the virtual machine
• Allows you to protect guests running operating systems not directly
supported by DSAs
DSVA – Architecture
• Main process running in the DSVA is called Master Agent
– Protects the DSVA itself
– Protects the virtual machines
– Creates and maintains a Virtual Agent for each endpoint that is
being protected
– Virtual Agent is a collection of files that are virtually identical to
those on a regular Deep Security Agent

DSVA – Architecture
• One-to-one relationship between VMs and virtual agents
• Master agent will create a Virtual agent for each machine on the ESX
server
• Virtual Agents are matched with VMs based on the VMs BIOS UUIDs

DSVA - Architecture
• VM network I/O is intercepted on the ESXi hypervisor

level
• Disk I/O is intercepted by the vShield VMCI Drivers

installed together with the VMware Tools

DSVA - Architecture
• Supported configurations for Deep Security 9.6 DSVA
protection:
– vSphere ESXi 5.x with VMsafe (using a Deep Security Filter Driver)
– vSphere ESXi 6.x without NSX (using Combined Mode with a DSA)
– vSphere ESXi 6.x with NSX

DSVA - Architecture
• Configuration One - vSphere ESXi 5.x with VMsafe

DSVA - Architecture
• Configuration Two - vSphere ESXi 6.x without NSX

DSVA - Architecture
• Configuration Two - vSphere ESXi 6.x without NSX
Combined Mode
IDS/IPS
Web Reputation
Firewall
Recommendation
Scan
Log Inspection

DSVA - Architecture
• Configuration Three - vSphere ESXi 6.x with NSX

VMware Environment
– NSX is the functional equivalent of a network hypervisor and reproduces
the complete set of L2-L7 services (switching, routing, access control,
firewall, QoS, load balancing) in software
– Equivalent of server virtualization (snapshots, deletes and restores for VMs
for software-based virtual networks)

ESXi with VMsafe Preparation
(Only applicable to Configuration One - ESXi 5.x with VMsafe)

As part of Filter Driver and DSVA deployment, the DSM performs the
following steps:
1) The ESX server creates a port group and a virtual switch as part of the
preparation process
vSwitch and Port Group Preparation
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, it must exist on both.
• External Communication vSwitch

– 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
– 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

2) DSVA driver is copied from the DSM to the ESX server
DSM vCenter ESX
 Driver location on DSM
 Driver location on DSM
Connect to DSM, download driver 
1. 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.
3) The ESX Server enters into Maintenance Mode.
NOTE: VMs on an ESX server will lose network connectivity when their host goes
into Maintenance Mode. For this reason, the DSM, vCenter Server, and vShield
Zones Manager cannot be installed on VMs that are hosted on the server that is
being prepared.
4) The ESX Server installs the driver upon itself. Throughout this process
the ESX server sends events to vCenter.
5) Once installation is complete, the ESX server is brought out of

Maintenance Mode.

NSX Preparation
(Only applicable to Configuration Three - ESXi 6.x with NSX)
• In environments with ESXi 6.x and NSX, there are a few requirements
and activities that must be performed as part of preparing the NSX
environment:
1. Datacenter must be using vSphere Distributed Switch (vDS)
2. ESXi Servers must be connected to the Distribution Switch
3. ESXi Servers must be grouped into Clusters, even if there is only a single
ESXi Server in a single Cluster
NOTE: The ESXi Servers must be connected to the vSphere Distributed Switch before
they are moved into clusters.
NSX Preparation
(Only applicable to Configuration Three - ESXi 6.x with NSX)
4. The Cluster must be prepared by installing the drivers that will allow
network traffic inspection on all ESXi Servers.
5. The Guest Introspection Service must be installed on the Cluster.
6. The virtual machines must belong to an NSX Security Group.
7. The virtual machines must have the latest VMware Tools installed,
including the Guest Introspection Driver.

DSVA – Activation
• DSVA activation works the same way as with DSAs
• DSVA needs to be activated to communicate with a DSM
• Both vCenter Server and vShield Manager Admin credentials are
required
– Because the DSM needs to know if the ESX host upon which the DSVA is being
installed is EPSec ready (EPSec service installed and properly registered with
vShield Manager)
• If you set up DSVA as a service in NSX, the appliance is
automatically installed and activated on a new ESX host that is
added to the cluster
– With NSX, the DSVA deployment is managed by vCenter/NSX and not by
420
DSM
Copyright 2016 Trend Micro Inc.
DSVA – 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 or
by right-clicking on the
VM
• Can take long depending on the number of VMs hosted on
the ESX server
• Virtual Agent does not actually exist until it is activated
• Activation creates the Agent’s subdirectory:

– /var/opt/ds_agent/guests
• DSVA Master Agent is responsible for these changes which

are all part of the VA instantiation process
• Viewing Protected VMs

Deep Security Notifier
• Windows System Tray utility for physical or virtual Windows
machines
• Provides local notification when malware is detected or
malicious URLs are blocked
• May be installed separately on VMs protected by a Virtual
Appliance (DSVA)
• Automatically installed as part of the Deep Security Agent
or Relay installation on Windows machines

DSVA Console
• Deep Security Virtual Appliance has its own console

DSVA Console
• Administrator can choose to use either the
command-line interface or the graphical interface
(GUI) to do the following:
– View 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

DSVA Console
• Administrators can open the command line interface by pressing Alt-F2
and access the bash shell
• Enter Alt-F1 to return to the graphical console

DSVA Console
• Press “F2” to open the user authentication dialog box, where administrators can
enter the password to access the console

DSVA – Communication
• To deploy and manage DSVA, the

DSM must be able to communicate
with the DSVA itself, and the
vCenter server that manages the
ESX server upon which DSVA is
installed

DSVA – Communication
Traffic Between: DSVA & DSM vCenter Server & DSM ESX & DSM
This is virtually identical to the traffic that The DSM needs this communication to This only applies to the state
would flow between a DSM and DSA. receive VM-related events. This includes: prior to DSVA deployment.
This consists of:  VM Creation
 Rule Updates  VM Start/Stop Events
 Log Events  vMotion Events
 Heartbeat Messages
Frequency Either according to heartbeat schedule The DSM always stays logged on to N/A
or upon Administrator intervention. vCenter Server.
If the connection is lost, the DSM tries to

re-establish communication every 10
minutes.
Effect when disrupted during N/A Will cause deployment to fail. Will cause deployment to fail.
deployment
Effect when disrupted during Will prevent rule updates and event Will prevent detection of VM creation N/A
normal operation consolidation at the DSM. Syslogs may and vMotion events. VM status
still work. indicators on the DSM will not be
updated.
DSM and VMware vCenter Server
• DSM communicates with vCenter Server to obtain information about
the virtual environment it is protecting
• DSM should have sufficient credentials to establish a relationship with a

particular Center Server instance
• Should this information change, Administrators need to update the

information by right-clicking the relevant vCenter Server from hosts tree
and selecting Properties

DSM and VMware vCenter Server
• General – Defines basic DSM and vCenter Server communication.( The

latter’s host information, communication port, and logon credentials
can be reconfigured here.)
• vShield Manager – Defines access to the vShield Manager, and is only
required when Anti-Malware functionality is used
• Network Configuration – 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.)
DSM – vCenter Servers Synchronization
• DSM synchronizes its information with vCenter Server frequently to
ensure that it captures any and all changes that occur within the virtual
environment (for example, VM creation, vMotion events, etc...)
• Although this synchronization occurs automatically, Administrators still
have the option to synchronize manually

Event-Based Tasks
• Event-Based Tasks define system responses for particular situations,
such as when a virtual machine is added or moved to a protected ESX
server
• Those events can trigger tasks such as activation or assigning a policy or
relay group

DSVA – Instant-on Protection
• DSVA can instantiate and activate Virtual Agents for virtual machines as
they are created and automatically assign a specific Security Profile
• Event-Based Tasks can trigger Instant Protection functionality when VMs
are added to a virtual environment protected by DSVA

VM Creation Detection

Deep Security Policy Integration with NSX
• As of Deep Security 9.6 SP1, you can choose to synchronize

ALL your Deep Security policies with NSX
• Creates a matching NSX Service Profile called a Mapped

Service Profile for each Deep Security policy

Synchronizing DSM Policies with NSX
• You can enable (on a per-NSX basis) Policy Synchronization
• Go to Computers, right-click the vCenter, and click

Properties
– On the NSX Configuration tab, select Synchronize Deep
Security Policies with NSX Service Profiles


• After enabling policy synchronization:
– Create an NSX Security Policy
• In the policy, select a Mapped Service Profile as the Service
Profile for: Guest Introspection Service, and Network
Introspection Services (Inbound and Outbound)
– Assign the NSX Security Policy to the NSX Security
Groups containing the VMs to protect
• VMs in the NSX Security Group are activated and assigned the
corresponding Deep Security policy automatically, without the
use of event-based tasks (EBTs)
• DSM will export all
DSM policies as NSX
Service Profiles into
NSX Manager
• Also creates an NSX
Service Profile,
called Default (EBT)
– Uses default event-
based tasks (EBTs)
behavior in Deep
Security 9.6
Creating NSX Security Policy
• When policy synchronization is enabled, you
will see all the Service Profiles when adding
the following introspection services:
– Guest Introspection Service
– Network Introspection Service (Incoming)
– Network Introspection Service (Outgoing)

Creating NSX Security Policy
• Important to select the same NSX Service
Profile for each of the Introspection services

Assign NSX Security Policy to NSX Security Group
• In the vSphere Web Client, go to Home >
Networking & Security > Service Composer >
Security Policies tab
• Select the new Security Policy and click Apply
Security Policy icon
• Under Apply Policy to Security Groups, select
Security Group that contains VMs to protect

Assign NSX Security Policy to NSX Security Group

Policies Locked in DSM
• After policy
synchronization is enabled,
VMs will be locked to a As soon as the NSX Security
particular policy as defined Group is deleted or
in the NSX Security Policy unassigned from the NSX
• Policy assignment is Security Policy, you will be
now completely able to change or remove
determined by the NSX
the Deep Security Policy in
Service Composer and
cannot be changed from
the DSM console
within DSM
Working with vMotion
• 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 – If the destination server has a DSVA installed
NOTE: By design, the DSVA cannot be migrated to another ESX server via vMotion.

• When a VM is transferred to another ESX server, its VA must also
be replicated at the DSVA on the receiving ESX server
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)

• The following Virtual Agent’s identity data is compressed into a .TAR file
and transferred using the VM communication channel (file size
maximum is 2KB)
– Certificates used for VA and DSM communications (ds_guest_agent.crt,
ds_guest_agent_dsm.crt)
– AM component version information
– System event database (ds_guest_agent.db)
– Miscellaneous vMotion-related data
• Integrity Monitoring-related data (si.db) can grow much larger and is
transferred via the Deep Security Relay
NOTE: If the DSR is not able to download its database, the VA will rebuild its
baseline.
VMware Endpoint Security (EPSec) System
ESX
DSVA VM
EPSec API EPSec API
(Anti-Malware
(VMTools)
daemon)
EPSec Read file

service
Write cleaned file
Hypervisor
• EPSec API components that reside within the Anti-Malware daemon on

DSVA
• EPSec drivers on the protected virtual machines
• EPSec service that is installed on the ESX hypervisor
DSVA – EPSec
• EPSec API contained within
• EPSec service installed using VMTools
VMware vShield Manager • Responsible for hooking I/O
events on the VM

DSVA – Anti-Malware Operations
Real-Time Scan in DSVA
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

DSVA – Anti-Malware Operations
On- Demand Scan in DSVA
• DSVA sends the requested list of directories, files and
exclusions and then starts receiving the enumerations of
events
• After analyzing the file, DSVA can request for the vShield
Endpoint to write the new content, truncate or delete the
file

DSVA – Operations Basics
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
• 1 Master Agent – Protects DSVA and instantiates Virtual Agents

• Virtual Agents – As many as the number of protected VMs
• Anti-Malware Daemon – Responsible for scanning and interacts with the common modules
• EPSec module – Link between DSVA and VM

DSVA – EPSec Responsibilities 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

DSVA – Responsibilities
DSVA
EPSec
Yes
Evaluate Determine scan type Use Covered by
event based on (Real-time/Manual/ corresponding additional Skip file
st
1 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

DSVA – Anti-Malware Scanning
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

Scan Cache Settings and Concurrent Scan
• Sequential Scans was put in place to avoid scan storms
• But then some on-demand/scheduled AM scans were taking

days or even over a week to complete
• As many VMs are similar, same file was scanned hundreds of

times

• De-duplication/Scan cache helps solve problem found in Agentless
environments related to VDI environment
• Can be specified for files and group of VMs
• Scan Caches are not shared between tenants. Files are segregated by a
combination of attributes: Tenant, Policy, Filename, File-Size,
modification time, USN (optional)
• Scan cache tries to cache certain files (high cost) that take longer to scan
• There is one cache for each of the following:
– On-demand scan
– Real-Time scan
– Integrity Monitoring Scan
• For security, the first 1 KB of file data will always be scanned
when used with Real-Time scan
• Gain of using Scan Cache can be as high as 20 X
• 1 million cache entries into the DSVA (memory) takes up
around 100 MB space (default policies in DSV is 500,000
entries)
• Cache is unique to each DSVA
– Information is not shared between them
• Available for Windows only
• Scan Cache settings are controlled at the policy level, and can be
accessed in:
– Settings > Scan > Virtual Appliance Scans
• Max Concurrent Scans
– Number of scans that the Virtual Appliance will perform at the same time
(Recommended number is four.)
• Max On-Demand Malware Scan Cache Entries
– Determines maximum number of records that identify and describe a file or
other type of scannable content to keep. (One million entries takes up
approximately 100MB of memory.)
• Max Malware Real-Time Scan Cache Entries
• Max Integrity Monitoring Scan Cache Entries

– Determines the maximum number of entities included in the
baseline data for Integrity Monitoring

Quarantine in DSVA
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

Quarantine in DSA
NOTE: If the limit is reached, the Quarantine action will fail, and the I/O
event that triggered the quarantine action will be blocked.

DSVA – Quarantine
• Quarantined files will be automatically deleted
from a Virtual Appliance under the following
circumstances:
– If a VM undergoes vMotion
– If a VM is deactivated from the Deep Security Manager
– If a Virtual Appliance is deactivated from the Deep
Security Manager
– If a Virtual Appliance is deleted from the vCenter
Integrity Monitoring – Agentless
• Agentless Integrity Monitoring uses the same EPSec
components as Anti-Malware
• Functionality in DSVA is limited to monitoring parts of the
system
– Files prior to vShield Endpoint 5.1
– Files and Registry since vShield Endpoint 5.1
• Baseline is stored in the Virtual Agent directory on the
DSVA
• Only works with VMs using Windows operating systems
Protection Modules on VMsafe
• Firewall, Intrusion Prevention, Web Reputation
(Only applicable to Configuration One: ESXi 5.x with Vmsafe)
• DSVA intercepts and analyzes network traffic intended for VMs
– Uses FastPath filter driver to intercept traffic
• Processing for Firewall protection occurs in vmKernel
– Intrusion Prevention and Stateful configuration consolidated in DSVA
• DSVA Recommendation Scan
– On Windows VMs only and limited to scanning: OS, Installed Applications,
Window Registry and File System
– Consequently, utilizes ~5% less rules compared to Agent-based scans
Protection Modules on NSX
• Firewall, Intrusion Prevention, Web Reputation
(Only applicable to Configuration Three: ESXi 6.x with
NSX)
• DSVA intercepts and analyzes network traffic
intended for VMs
• NSX DVFilter Driver configured to redirect traffic
to DSVA where ALL processing occurs

Lab 15: Installing vShield Driver
Lab 16: Add vCenter Server
lab 17 or 18: Deploying DSVA

Chapter 14: Cloud

Cloud Computing
• Characteristics of cloud computing
– On-demand
– Self-service
– Pay-per-use
– Accessible over internet

Cloud Deployment Models
• Public Cloud
• Private Cloud
• Virtual Private Cloud
• Hybrid Cloud

Cloud Computing Services
• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Software as a Service (SaaS)

Deep Security in the Cloud
• Amazon Web Services (AWS)
• Microsoft Azure
• vCloud Air

AWS

Azure

vCloud

Deployment and Installation
• Open required ports
• Create DSM account
• Install DSM
• Configure direction of communication

Agent-Initiated Communication

Deployment Scripts

Deployment and Installation
• Certificate (Azure only)
• Import Computers for Protection
• Inline Sync
• Reactivate Cloned/Unknown VM

Thank You!
EDUCATION@TRENDMICRO.COM
HTTPS://WWW.SURVEYMONKEY.COM/S/TRENDMICROTRAINING

DeepSecurity 9.6SP1 CertProf Slides FINAL 28jan2016

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DeepSecurity 9.6SP1 CertProf Slides FINAL 28jan2016

Transféré par

Droits d'auteur :

Formats disponibles

Deep Security 9.

2 Copyright 2016 Trend Micro Inc.

3 Copyright 2016 Trend Micro Inc.

4 Copyright 2016 Trend Micro Inc.

5 Copyright 2016 Trend Micro Inc.

Physical Virtual Cloud

Dedicated Server Desktop & Server Private, Hybrid &

7 Copyright 2016 Trend Micro Inc.

8 Copyright 2016 Trend Micro Inc.

9 Copyright 2016 Trend Micro Inc.

• Integrates with Trend Micro Smart Protection Network to

• Same behavior in both Agentless and Agent-Based DSAs

11 Copyright 2016 Trend Micro Inc.

• Based on VSAPI and SPN

• Real-Time, Scheduled or Manual

12 Copyright 2016 Trend Micro Inc.

14 Copyright 2016 Trend Micro Inc.

16 Copyright 2016 Trend Micro Inc.

Public Cloud IaaS LDAP/AD

Virtual Appliance Support

Relays Smart Protection

Windows Linux Solaris HPUX/AIX Windows Linux

17 Copyright 2016 Trend Micro Inc.

18 Copyright 2016 Trend Micro Inc.

19 Copyright 2016 Trend Micro Inc.

• Relays Security Updates from Trend Micro Global Active

• At least one DSR is always required for a DSM (can be

20 Copyright 2016 Trend Micro Inc.

21 Copyright 2016 Trend Micro Inc.

22 Copyright 2016 Trend Micro Inc.

23 Copyright 2016 Trend Micro Inc.

25 Copyright 2016 Trend Micro Inc.

• Terms and Conditions

27 Copyright 2016 Trend Micro Inc.

• Security Module Usage Cumulative Report

• Deep Security Agent Activation Secret

29 Copyright 2016 Trend Micro Inc.

• licensed directly through Deep Security Manager.

IBM QRadar Support

31 Copyright 2016 Trend Micro Inc.

Additional Platform Support

32 Copyright 2016 Trend Micro Inc.

Active Directory Synchronization on Login

33 Copyright 2016 Trend Micro Inc.

Minor Report Enhancements

Automatic Updates of Online Help

34 Copyright 2016 Trend Micro Inc.

35 Copyright 2016 Trend Micro Inc.

36 Copyright 2016 Trend Micro Inc.

37 Copyright 2016 Trend Micro Inc.

38 Copyright 2016 Trend Micro Inc.

• A two millisecond (2 million nanoseconds)

39 Copyright 2016 Trend Micro Inc.

40 Copyright 2016 Trend Micro Inc.

41 Copyright 2016 Trend Micro Inc.

42 Copyright 2016 Trend Micro Inc.

• Over 1000 computers, the Deep Security Manager

44 Copyright 2016 Trend Micro Inc.

• To calculate the required disk space, multiply the

45 Copyright 2016 Trend Micro Inc.

46 Copyright 2016 Trend Micro Inc.

• Similar settings are available for Firewall and Intrusion

48 Copyright 2016 Trend Micro Inc.