TMS zl Module Planning and Implementation Guide 2009-08

Page 43
Developing specific Virtual Private Network (VPN) requirements will not be addressed
in this document but typically encompass identifying network traffic paths that require
encryption. The details gathered from research and discussion with the customer IT staff
will provide the foundation for identifying a need (or not) for VPNs to properly protect
this customer’s information assets. Encryption may be required due to the type of traffic,
such as credit card transaction traffic, or due to paths the traffic will take, such as a
remote office connecting to the central datacenter over a public Internet connection.
More information on VPNs using the TMS zl Module is covered in Section 10 of this
document and in Section 7 of the HP ProCurve Threat Management Services zl Module
Management and Configuration Guide. For additional information on Virtual Private
Network concepts, you can refer to materials such as “Virtual Private Networks”
published by O’Reilly.
Specific IDS/IPS design requirements will also not be discussed in depth in this
document. However, now that a significant level of information has been gathered on the
network design and protection requirements for this customer, this data can be used to
determine if and what type of an IDS/IPS solution is appropriate. To avoid unexpected
application communication issues, it is important to a have proper level of understanding
of each application and its interaction with other network resources. Specific legitimate
network traffic may trigger a “false positive” by some IDS/IPS detection patterns causing
it to be incorrectly detected or prevented as an “intrusion.” Because of this, it is
important that server and TMS logs are reviewed and any anomalies are investigated after
implementation or whenever additional signatures are enabled. For further discussion on
this topic, see Section 6 of the HP ProCurve Threat Management Services zl Module
Management and Configuration Guide.
The last topic covered in this section is developing a set of firewall rules that provide
proper level of protection for network traffic flowing between the configured TMS
Zones. Caution should be taken in defining and implementing firewall rules, especially
for internal server communication. Due to the high amount of internal server
communication, over-restrictive rules can lead to unintended blocking of access to
servers. This could adversely impact end-user access or important server security
communication such as access to Windows Active Directory. It is important to be sure
that the table of network details has been verified using tools ran against each server,
such as Process Explorer and TCP View, versus only taking port information from
product manuals. Keep in mind that once rules are put in place to restrict
communication to and from each server, that nothing other than what is explicitly
allowed will be able to reach the server. If a key network port is not included in the rules,
the server communication will not be permitted to pass. One common area that is
overlooked is the Active Directory communication that happens for all servers joined to
an AD domain. If the server cannot reach a Domain Controller, the server may
eventually “tombstone” in Active Directory. This can lead to client access to the server
being denied, among other issues. To help avoid this type of situation, in addition to
application-level validation activities, the OS and application event logs of servers should
be reviewed for a period of time after these rules are implemented to ensure that no
anomalies arise.
Based on the information gathered in previous steps, we should now have a solid
understanding of the specific requirements needed to determine specific firewall rules for