Deep Security 7 TOI

1. Deep Security 7 TOI Deployment Considerations

2. Agenda for Deep Security 7.0 Deployment Considerations • Deep Security Manager and Database • Deep Security Agent • Recommendation Scans • Firewall • Deep Packet Inspection • Integrity • Log Inspection

3. Agenda for Deep Security 7.0 Deployment Considerations – DSM and DB • Supported DB Vendors • DB Schema • DB Location • DB Size • Event Retention • DB Notes

4. Agenda for Deep Security 7.0 Deployment Considerations – DSM and DB • Communication Method • Heartbeat Frequency • Multiple DSM Nodes • SMTP Requirement • Agent Update Method • Security Center Communication • Security Center Updates

5. Supported DB Vendors • Embedded • Only to be used for demo’s/trials • Runs co-located with DSM, does not perform very well • Migration is difficult (but possible) • MS SQL Server • 2005 + 2008 supported • Most customer proven and tested option • Appears to perform best • Oracle 10g • Other versions of Oracle could likely be supported with testing • Few customer deployments

6. Database Schema • Schema is complex, and almost identical on all DBs • Differences are minor and concern some modifications for indices • Filled with application specific knowledge • Only in extreme circumstances should queries be run directly on the DB

7. Database Location • Database must be located nearby all DSM nodes • Over 1 Gb LAN is ok – over WAN is not • Can use Database Ping Time in System Information to determine if problems may exist (times >2ms or >2 million ns may be problematic)

8. Database Location (cont.) • Database communication is NOT encrypted by default • Suggest having the database physically connected via crossover, or on isolated switch • If this is not possible, and data is vulnerable to snooping, encryption should be enabled (with inevitable performance impact) • Can be enabled via properties files • All details in DSM OLH: “Encrypting DSM to DB Communication”

9. Database Size • The maximum amount of data should be pre-allocated • Autogrowth is expensive and should be avoided • Ensure lots of space available for DB log/undo space • 20GB or more • Data files should be configured on different physical disks • Rough guidelines for data • ~110 MB – fresh install, no Computers • ~1GB fixed storage, updates, profiles, rules • ~10 – 50 MB / Computer ongoing • Varies mostly with amount of security events being generated and retained

10. Database Event Retention • Retention is VERY important to maintaining a reasonably sized database • Default times are: • 7 days for security events (FW, DPI, IM, LI) • Bulk of the data is here • “Never” for system/agent events • Useful for audit history, can be large but much smaller in 7.0 due to lack of recommendation audit history • 12 weeks for counters • Only useful for reports, very small in comparison • Based on the deployment characteristics, tune these as necessary

11. Notes • SQL Server runs very well with many cores • Set the Max Memory for SQL Server • ~200MB less than what the system has (minus other apps that need stuff). • Vanilla system with 4GB, give SQL Server 3800MB. • System + DSM, assume about 1500MB for DSM, so give SQL Server 2300MB

12. Communication Method • 3 methods supported (Manager Initiated, Agent Initiated, Bi-Directional) • Can be set at the Global, Security Profile and Computer level • Bi-Directional is the recommended default method and used in most production deployments • Manager Initiated typically used for DMZ hosts that can’t reach the Manager in the Datacenter • Agent Initiated good for environments where the Agent is behind a firewall such as mobile workstations

13. Heartbeat Frequency • Can be set at the Global, Security Profile and Computer level • Default value of 10 minutes is used in majority of production deployments for server • 60 minutes recommended for workstations • Events are delivered to DSM in blocks of 1,000 during Heartbeat • Biggest factor when choosing the frequency is the acceptable amount of time between when an event triggers and when the events are delivered to the DSM

14. Heartbeat Frequency • Becomes less of a factor if the customer is sending events real time to a third party product via Syslog (SIEM) • Choosing a frequency too low can have a negative performance impact on the DSM resulting in the DSM not being able to accept the heartbeat • If heartbeat fail due to lack of network connectivity with the DSM, events will be stored locally until connectivity is restored

15. Mutiple DSM Nodes • Nodes must share the same DB which typically means they are located in the same datacenter • Agents will use all DSMs in a round robin fashion (Agent Initiated or Bi-Directional) • Each node can support approximately 10,000 Agents (7.0 on a 64bit platform) • For deployments larger than 1,000 Agents a second node is recommended for redundancy • Geographic dispersion not currently supported • Administrators can access either node for Administration

16. SMTP Requirement • SMTP server required for DSM to send email messages (Alerts, Reports, etc) • SMTP authentication supported • Non-standard ports supported by adding :<port> to the mail server address (ie mail.trendmicro.com:587)

17. Agent Update Method • Agents can be updated automatically, manually or by a scheduled tasks • Automatic update is the default but not recommended in Production environments as the Administrator loses control over when updates occur • Manual updates allow more control for an Administrator to follow their existing change control process • Manual updates prevent multiple updates from occurring during Security Profile modification (in automatic an update occurs every time the save button is pressed)

18. Agent Update Method • Administrators may forget to update the host in manual mode • Last Update Required and Last Successful Update fields on the Host properties screen can be used to identify these cases • Scheduled Tasks can be used to update hosts during maintenance windows, off hours, etc. • Some customers perform scheduled updates nightly to ensure no manual updates were forgotten

19. Security Center Communication • DSM requires raw socket connection to Security Center • SOCKS proxy required, standard HTTP proxy will not work • Customers who have proxies that support installed clients, such as the Windows ISA proxy, can install the client on the DSM machine however the following should be taken into consideration: • DSM Windows Service may need to be modified to use a specific account in order to authenticate to the proxy • This modification is reversed during product upgrade and will need to be performed again • If the account is locked out or the password expires, DSM may fail to start

20. Security Center Updates • Automatic download of Security Updates is recommended • Automatic download and apply of Security Updates is not recommended • It is a best practice to perform a Recommendation Scan after applying a new Security Update • The default setting of Allowing Security Updates to automatically assign new DPI Rules is not recommended in production environments

21. Security Center Updates • Application of Security Updates in Detect Only mode may cause complications: • Once one Update is in Detect Only mode all updates applied after are in Detect Only mode as well • If multiple updates are applied in Detect Only mode they must all be switched to Prevent mode at the same time so you can’t switch the second newest update to Prevent Mode without changing the newest one as well • Proper processes around the management of Security Center updates is necessary

22. Agenda for Deep Security 7.0 Deployment Considerations – DSA • Local Logging • FW and DPI log • Agent Database • Log Inspection DB Info • Integrity DB Info

23. Local Logging • All Agents events are stored locally until a heartbeat occurs • Four different locations: • %WINDIR%\System32\LogFiles\ds_agent\dsa_mpnp • %ProgramFiles%\Trend Micro\Deep Security Agent\ds_agent.db • %ProgramFiles%\Trend Micro\Deep Security Agent\si.db • %ProgramFiles%\Trend Micro\Deep Security Agent\lca.db

24. FW and DPI event log • Stored in one file %WINDIR%\System32\LogFiles\ds_agent\dsa_mpnp (New in 7.0) • Rolls over based on configuration settings – Default is 3 logs x 4 MB each • If low disk space is detected older files are removed to make room for new events

25. Agent Database • Stored in one file %ProgramFiles%\Trend Micro\Deep Security Agent\ds_agent.db • Unencrypted SQLite3 database • Contains miscellaneous DSA settings and DSA system events that haven’t been delivered to the DSM

26. Log Inpsection DB Info • Stored in the file %ProgramFiles%\Trend Micro\Deep Security Agent\lca.db • Encrypted SQLite3 database • Contains LI events that haven’t been delivered to the DSM • Once fetched, IM events are deleted from this database, however the DSA will keep up to 2000 IM events in the local DB for display in the local GUI • Will grow in proportion to the number of pending LI events and the amount of string data in each record • Maximum file size of 64MB, if this is reached no new events are recorded until these events are delivered to the DSM and flushed • If free disk space drops below 5MB, Log Inspection will stop recording events until free space is above 5MB

27. Integrity DB Info • Stored in the file %ProgramFiles%\Trend Micro\Deep Security Agent\si.db • Encrypted SQLite3 database • Contains Agent’s local version of the Integrity baseline, plus any IM events and old baseline data that have yet to be fetched by the manager • Once fetched, IM events are deleted from this database, however the DSA will keep up to 2000 IM events in the local DB for display in the local GUI • Can be rather large - its size will be proportional to the number of objects in the baseline and the number of attributes the DSA has been asked to monitor per object • If free disk space drops below 5MB, Integrity Monitoring will be suspended until free space is above 5MB

28. Agenda for Deep Security 7.0 Deployment Considerations – Recommendation Scans • Benefits • Disadvantages • Scan Type • Scan Frequency • Choosing Targets • Applying Recommendations

29. Benefits • Helps determine what protection should be applied to/removed from a computer • Works for DPI, Integrity and LI modules • Results visible to computers and security profiles • Drastically reduces the effort involved with managing tens or hundreds of security profiles • Recommendation alerts and reports can assist with security profile management

30. Disadvantages • Thought needs to be put into the design of the recommendation scan methodology, simply scanning all hosts may have performance impact • Automatic assigment/unassignment can’t be done at the security profile level

31. Scan Type • DSM supports 3 modes for running Recommendation Scans: Manual, Ongoing and Scheduled • Manual scans are useful during the Security Profile creation process • With ongoing scans you can control the frequency of the scans (daily, weekly, etc) however you lack the control of choosing the time when the scan occurs • Scheduled tasks provide the most control for the scans and is the most widely used option

32. Scan Frequency • Recommended best practice from Professional Services is weekly recommendation scans • Recommendation Scans can heavily tax the DSM so scanning too frequently can result in poor DSM performance • Systems that don’t change often (servers) can be scanned less frequently • Systems that lack control over when changes occur (workstations) should be scanned more frequently • Scans should be performed after major changes to the computer to determine any additional required protection

33. Choosing Targets • Performing scans on all computers in a deployment may be impractical • In cases where systems are similar, scanning a subset of the systems may be optimal (ie retail environment where 1,000 computers are based off the same image) • If performing scheduled scans on a large number of computers, scanning the systems in groups is recommended

34. Applying Recommendations • It is a best practice that recommended rules be assigned to Security Profiles and not directly to computers • When applying rules to a Security Profile shared by many hosts the recommendations for that profile are based on the recommendations of all scanned hosts (ie if a Windows IIS rule is recommended on only one host, it will be recommended for the Security Profile and assigned to all hosts) • Allowing the recommendation engine to automatically assign rules is not recommended • Checking for rules that are no longer recommended can be easily overlooked

35. Agenda for Deep Security 7.0 Deployment Considerations – Firewall Module • Engine Modes • Rule Types • Rule Priorities • Best Practices

36. Engine Modes • TAP mode created for customers who want inspection to not interfere with traffic • Inline • Recommended operating mode • Processes actual packets • Firewall will block traffic not allowed by policy • Allows DPI to be in Prevent or Detect mode • TAP • Creates a copy of packet and forwards original up to the stack • Recommended as a fallback more for troubleshooting purposes • DPI can only be in Detect mode when the engine is in TAP mode

37. Rule Types • Allow – this action explicitly allows traffic that matches the rule to pass • Bypass – this allows traffic to bypass both firewall and DPI analysis. Use this setting only for media-intensive protocols. Only the port, direction and protocol can be set with this action. • Deny – this action explicitly blocks traffic that matches the rule

38. Rule Types • Force allow – this forcibly allows traffic that would otherwise be denied by other rules. This action type must be used for UDP and ICMP traffic. • Log only – traffic will be only be logged. No other action will be taken

39. Rule Priorities • Priorities 0-4 • Allow rules are priority 0 • Log Only rules are priority 4 • The priority determines the order in which rules are applied. High priority rules get applied before low priority rules. For example, a port 80 incoming deny rule with a priority of 3 will drop a packet before a port 80 incoming force allow rule with a priority of 2 ever gets applied to it.

40. Firewall RulesPriority Tree Incoming Traffic Priority: 4 – Highest Log Only Bypass Force Allow Deny Priority: 3 – High Deny Force Allow Bypass Priority: 2 – Normal Bypass Force Allow Deny Priority: 1 - Low Deny Force Allow Bypass Priority: 0 - Lowest Bypass Force Allow Deny Allow

41. Best Practices • Although Firewall rules are host specific, it is still recommended that this protection be assigned at the Security Profile level • A common method for determining if hosts should share the same Security Profile is to determine if they would also require the same Firewall configuration • If you are unsure which ports are required on a system the netstat command can help: • netstat -nap tcp | find "LISTEN” (Windows TCP) • netstat -nap udp (Windows UDP) • netstat -na | grep tcp | grep ”LISTEN” (Other TCP) • netstat -na | grep udp (Other UDP)

42. Best Practices • In the current release, allowed connections are not logged. In order to log allowed incoming TCP connections you can use the following trick: • Create an outgoing firewall rule using the “Log Only” action • In the rule properties select TCP as the protocol and for flags choose the SYN/ACK flags • Disabling the logging of UDP and ICMP stateful events can reduce a large amount of FW events

43. Agenda for Deep Security 7.0 Deployment Considerations – DPI Module • Engine Modes • Rule Types • Application Control • Web Application Protection • Best Practices

44. Engine Modes • Inline Detect • In Inline Detect mode, if a DPI rule triggers an event is generated and the packet continues up to the application • Recommended mode to start with for new deployments in order to identify any false positives • Inline Prevent • In Inline Prevent mode, when a DPI rule triggers an event is generated and the connection is reset • Rules can be individually changed to be in Detect Only mode • Some rules can’t function in Prevent Mode and will only work in Detect Only mode regardless of the engine mode • TAP • Similar to Inline Detect but also puts FW in TAP mode

45. Rule Types • Exploit – Exploit rules are written to protect against a specific exploit or type of exploit, low risk of false positives • Vulnerability – Vulnerability rules are written to prevent the vulnerability from being compromised by any exploit, low risk of false positives • Smart – Smart rules are rules that can be used to ensure the traffic conforms to certain restrictions. These rules typically require configuration and false positives can occur until they are configured correctly. • Custom – Customers can write their own rules using basic pattern matching or the RuleScript language

46. Application Control • Rules must be manually assigned (not recommended) • Can be helpful in enforcing security policies by detecting the use of applications or protocols that are not allowed • Typically used in Detect Only mode however a small number of rules can only be in prevent mode due to the way the application protocol works • Configuration is typically which ports to monitor/ignore and the frequency to generate events when this rule triggers (only generate an event once per minute, hour, day, etc) • Most rules are configured to generate an event once per day by default

47. Web Application Protection • Rules must be manually assigned (not recommended) • The following raw characters are considered illegal and should be URI encoded: 0x00-0x20,[,],<,>,|,\,^,`,0x7f-0xff • Illegal character list causes many false positives and requires configuration before switching to prevent mode • HTTP Protocol Decoder rule is a required dependency and configuration of many options, including illegal character list, is done through this rule • URI Normalization is done on the URI as well as HTTP POST bodies

48. Web Application Protection • For the rules that have both Allowed and Disallowed versions, only one of them should be used to establish a whitelist or blacklist (ie Allowed Resources or Disallowed Resources) • All rules require configuration and should never be assigned in prevent mode without a soaking period • Cross Site Scripting and SQL Injection rules are configured to catch majority of attacks by default, the best approach to customizing these rules should be to change the drop score for specific resources that are causing false positives and not the global drop score

49. Web Application Protection • Customers who have output from Web Application Vulnerability Scanners should leverage that information when applying protection (ie if username field on login.asp page is vulnerable to SQL Injection, ensure the SQL Injection rule is configured monitor that parameter with a low threshold to drop on)

50. Best Practices • Recommendation engine should be used to determine the majority of rules to be assigned • Rules should be assigned to a Security Profile and not to the host directly • If a specific rule is causing false positives, place that rule in Detect Only mode or unassign it • Any rule requiring configuration should be assigned in Detect Only mode until the rule can be configured for that computer • Stateful inspection still takes place on DPI enabled ports regardless of the FW state