TMS zl Module Planning and Implementation Guide 2009-08
Table Of Contents
- Contents
- Glossary of Acronyms and Abbreviations
- 1.0 Purpose
- 2.0 Intended Audience
- 3.0 Objectives
- 4.0 Prerequisites
- 5.0 Skills
- 6.0 The HP ProCurve Threat Management Services zl Module
- 7.0 Common TMS Security Control Points
- 8.0 Deployment Considerations
- 9.0 Installation and Preparation of the TMS zl Module
- 10.0 Configuration of the TMS zl Module
- 11.0 Using multiple HP ProCurve Threat Management Services zl Modules
- Appendix A – Additional References
- Appendix B – Sample Company Information Assets Spreadsheet
- Sample “Information Assets” tab (See Embedded “Company Information Assets” Microsoft Excel 2003 spreadsheet)
- “Server Network Details” tab (See Embedded “Company Information Assets” Microsoft Excel 2003 spreadsheet)
- “TMS Zones” tab (See Embedded “Company Information Assets” Microsoft Excel 2003 spreadsheet)
- “Firewall Rules” tab (See Embedded “Company Information Assets” Microsoft Excel 2003 spreadsheet)
- /Sample “Company Information Assets” Microsoft Excel 2003 spreadsheet
- Appendix C – Information Gathering Tools
- Appendix D - Updating Switch Software
- Appendix E – Emergency Recovery Process
Page 33
Figure 14: Functional Compartmentalization Security Control Point(s)
The example shown above in Figure 14 is a layered security variation on the
Perimeter/Compartmentalization college campus network scenario shown previously. In
this example, a corporate network is protected by one TMS zl Module at its perimeter
with that module’s Internal zone being the same VLAN as the External zone of an
additional TMS zl Module that provides another layer of security control to the corporate
network. This implementation compartmentalizes the higher-risk Research and
Development portion of the corporate network from the sensitive-data residing in the
Human Resources and Accounting portions of the corporate network.
7.3.1 Firewall
The basic guiding principle of a firewall is that of least privilege. Ideally, only
network traffic between security zones that has a legitimate, documented-in-
the-security-policy business need to traverse the zone boundary at the firewall
should be permitted. In specific policy terms, this typically translates to
identifying application components residing in one or more zones. This
includes the specific network communications between internal or external
users of that application and each application component. This may also
include the specific network communications needs between components of an
application that reside in different security zones. All other traffic should be
prohibited.