Firewall Wizards mailing list archives
(no subject)
From: "Wigg, Guy G" <GWigg () mail sbic co za>
Date: Tue, 16 Jan 2001 17:29:46 +0200
Hi Wizards Currently our organisation is designing a DMZ strategy. The strategy is far from finished, but I thought I would like to share with you some of our thoughts. As the strategy progresses I will send updates. I would really appreciate input as to whether we are on the right track or not. thanks Guy Organisation's DMZ strategy Terms used: DMZ - Demilitarised Zone Definition: Some type of network access control device (firewall, bastion host or router) that restricts access to a network zone creates a DMZ. A DMZ may be single layered (one firewall with min three interfaces) or multilayered (two or more firewalls with at least two interfaces) The DMZ was traditionally the segment between the Internet router and the bastion host or gateway into the network. It was where you placed your "sacrificial lambs", or machines which had to be publicly accessible, but which were dangerous to host inside. The DMZ is just another network zone with a particular level of trust. Objective: To provide a secure infrastructure that will allow the organisation to host its servers that need to be accessible either to devices/individuals on the Internet, internal Network or devices/individuals on a 3rd party network. The DMZ must be designed in such a way that if a single server in the DMZ is compromised the entire organisation's servers in the DMZ are not exposed and certainly not those with a higher security classification than the compromised server. The design must ensure that access to a DMZ server even through hacking from the Internet does not imply access to the backbone network. Compromise to a 1st line server in the DMZ must not imply access to customer or other organisation sensitive data. The design must be simple. Processes must be put in place within the DMZ to ensure the confidentiality, integrity and availability of the organisation's information is maintained. Roles and responsibilities with respect to the DMZ infrastructure must be clearly defined. See appendices. Adequate audit trails and monitoring of events must be carried out and made available to authorised individuals. Processes must be put in place to ensure consistent and effective management and administration of servers. Access will be granted to a security zone only on a need to have basis. Defining security zones and security classification level of servers: The DMZ must be designed by grouping servers with similar protection requirements together. These groupings will be placed into security zones that will cater for their protection requirements. The business functionality of the servers must also be taken into account. The protection mechanisms put in place in the various security zones will be defined by security principles such as access control to the zone (both physical and logical), identification and authentication of users and the auditing and management of servers. Principles will promote the confidentiality, integrity and availability of information. The following security zones have been defined for the organisation, Security zones: Red, Orange, Yellow and Blue. Security zone Red has the most stringent security mechanisms in place followed by Orange, Yellow, Blue and Clear respectively. A higher level zone by default inherits all security principles of lower zones and will also have its own additional security principles. The various applications and servers used in the organisation have been categorised into the following business zones: The Business Info Zone (This Zone encompasses servers that only provide informational services to the client/user). The RAS Zone (This Zone encompasses servers/devices that provide a mechanism for secure remote access to the organisation's backbone network). The Web surfing/Email Zone (This Zone encompasses servers that that facilitate email and web surfing e.g. web proxies and Exchange servers). The Revenue Generating / Transactional Zone (This Zone encompasses servers that facilitate an environment within which a user/client can carry out e-commerce type transactions). The Data Zone (This Zone encompasses servers that contain all confidential information, customer information or the organisation's business critical information) The Development/UAT Zone, (This Zone encompasses servers on which development code is housed and is tested) The Clear Zone, (This Zone encompasses a device or user that has access or makes up the untrusted network). It has been decided that the above business zones fall into the following security zones: Bus Zone / Sec Zone Red Orange Yellow Blue Clear Data Zone X X X X X Revenue Generating / Transactional Zone X X X X Test / UAT Zone X X Web surfing / Email Zone X X X Info Zone X X X RAS Zone X X X Security Principles General When moving from a lower to a higher security zone access must be controlled by a network device, this control can range from an ACL on a router to a rule on a firewall depending on the security principles defined for each zone below. Access at a network level must be controlled between two equal security zones, or going from a higher to a lower security zone if the security zones intersect with different business zones. This is in line with the need to have principle (objective 8). Eg. Access to one yellow security zone does not imply access to all Yellow security zones. Where ever possible establishment of data connections between various security zones must always take place from the higher to the lower security zone. The connection device that connects two security zones must be configured according to the security principles of at least the higher security zone. Where a perimeter router is the only network access control device between two zones it should be configured at a red level. By default all access control devices must deny all traffic. All access control devices must fail into a closed state. Principles that apply to each security zone The Red Zone The zone must be homogeneous with regards to the host operating system. Security services and mechanisms Zone Access Identification / Authentication FW rules must only permit admin access to the zone if there is a clear permitted service following the need to have principle and an internal source IP address. In the case of DHCP firewall authentication could be used. Anti-spoofing rules must be applied to all the firewall's interfaces. Remote support users must authenticate using a one time password or token as close to the zone as possible. Access Control With respect to firewall rules, traffic between the zones must use the minimum required source and destination addresses and services. Confidentiality Where end to end confidentiality cannot be maintained, encryption as close to the zone as possible Integrity still to come Availability still to come Audits and Compliance still to come Other zone's security principles still to come.
Current thread:
- (no subject) vonkie (Jan 05)
- Re: (no subject) M.Schubert (Jan 08)
- Re: (no subject) R. DuFresne (Jan 08)
- <Possible follow-ups>
- RE: (no subject) Kalat, Andrew (ISS Atlanta) (Jan 08)
- (no subject) Wigg, Guy G (Jan 16)