TMS zl Module Planning and Implementation Guide 2009-08

Table Of Contents
Page 34
A common example is the typical n-tier database-driven web site. The web
server front-end (often Apache or IIS) sits in the DMZ security zone. The
database server (frequently Oracle, mySQL or SQL Server) is sited within the
data center security zone or a more specific database servers security zone
within multiple zones in the data center. A policy with rules for permitting
HTTP (TCP/80) traffic originating from the External security zone passing into
the DMZ security zone must be created to allow the necessary first tier
network communications between the Internet end users and the web server
front-end component of this n-tier application. Another policy with rules
permitting SQL traffic (TCP/1521 for Oracle, TCP/3306 for mySQL,
TCP/1433 and possibly UDP/1434 for SQL Server) originating from the front-
end web server in the DMZ security zone passing into the internal, data center
or specific Database-Servers security zone must be created to allow the
necessary second tier communications between the web server front-end
application component and the database server back-end application
component. In the event of e-Commerce support this scenario may also
involve a middle tier with a transaction processor, for example, BEA Tuxedo
or Microsoft Transaction Server.
7.3.2 IDS/IPS
The fundamental principle involved with Intrusion Detection/Prevention is to
decide whether passive detection and reporting is sufficient or if active
prevention, and potential undesired interference with legitimate application
traffic, is desired. Next, the system needs to be “tuned” to address the security
concerns while eliminating “noise.” Active intrusion prevention requires
operation in routing mode. Passive intrusion detection and reporting is
provided by a TMS zl Module operating in monitor mode. Passive intrusion
detection is also possible in routing mode by configuring all actions to allow
traffic.
Once the requisite operating mode has been determined, the module
configured, signature update subscriptions have been enabled, and intrusion
signatures successfully downloaded for the first time, the system may require
tuning. In monitor (IDS) mode, tuning involves deciding what traffic gets
mirrored to the module, disabling a signature or adjusting settings for any
protocol-specific anomaly that is generating a large number of “false positives”
in the logs. In routing (IPS) mode, it involves similar configuration changes as
in IDS mode to avoid incorrectly preventing the flow of legitimate application
traffic. An additional, large-scale tuning mechanism on the TMS zl Module is
the configurability of actions to be taken on the predefined threat levels of the
intrusion signatures, though generally, the defaults provided will be sufficient.
Unlike the firewall, it is not possible to only apply selected intrusion signatures
or protocol-specific anomaly detection parameters to traffic traversing between
specific zones. Disabling an intrusion signature or tuning a protocol-specific
anomaly identification parameter is done globally, and so the benefits (ie. false
positives vs elimination of legitimate traffic being blocked) must be carefully
weighed against any additional information security risks possibly incurred by