PAT.Data Zone Protection

Informational

Page maturity
This page has maturity level 3 (usable)

	PAT	Data Zone Protection	Version:	0.2
	Document type:	Pattern Type	Owner:	J.A.H. Schoonderbeek

Informational

Create commentary

Description

This Pattern Type belongs to "Infrastructure Sector Core". Two or more data transport zones may need to be separated because of different security-related requirements. If this is the case, then traffic from one zone traveling to the other zone needs to be processed so as to satisfy the security requirements imposed by the separation. To this end, this pattern may be employed.
In practice, use of this pattern often leads to use of a firewall device, but as security requirements evolve, so may the realization of this pattern.

Graphical Overview

This is the graphical representation of the infrastructure functions in this Pattern Type, plus their main relations:

(The source file of this picture can be downloaded here).

Pattern Type Composition

This pattern has the following mandatory and optional subfunctions, expressed in Building Block Types:

Icon	Function	WA	Inclusion	Rationale
	Traffic Filtering	NW	mandatory	This facility performs the actual filtering of traffic flowing from one data zone to the other. The filtering is based on rules that are derived from the security requirements, e.g. "no traffic is allowed from the DMZ to the internal network, with the exeption of ...". Note that the storage of these rules call for a Permission Store, and execution of the rules is in fact Permission Validation.
	Data Scanning	SE	optional	When filtering based on traffic characteristics is not enough, filtering based on data (content, deep inspection) may be needed. This can be useful for securing message exchange between zones (e.g. e-mail or SOAP messages), but also for deep inspection in certain protocols. This can for example detect malicious commands inside protocol packets, e.g. SQL injection instructions inside a HTTP request. When data scanning reveals a problem, a fitting action must be undertaken by another facility (e.g. the Traffic Filter may drop the packet or block the sender, or Monitoring may issue an alert).
	Control Interface	SE	optional	If there's a need to describe the interfacing with Traffic Filtering (e.g. by administrators, or maybe end users), then this function can be used for that.
	Distribution	NW	optional	Since this Pattern often is used as a chokepoint where all data traffic must go through, it is also a good point to locate Distribution.
	Load Balancing	NW	optional	Since this Pattern often is used as a chokepoint where all data traffic must go through, it may be necessary to include Load Balancing to provide higher availability of this Pattern.

Pattern Type Neighbors

This pattern has the following mandatory and optional relations with adjacent (sub)functions, expressed in Pattern Types (PAT). Note: if the table below is empty, then there are no architecturally prescribed relations with adjacent subfunctions:

Function	Adjacency	Description
Data Transport	mandatory	While Data Transport usually serves to link the facilities within a Pattern, in this case it also serves as the customer for this Pattern: Transport Zone Protection sits between two or more Data Transport Zones.
	optional	Transport Zone Protection is usually employed to enforce security levels within one or more Data Transport Zones; thus, many events that occur in a Transport Zone Protection facility are of interest to the security officers. This means it is very desirable to have the facility report directly to Security Management & Auditing.
Authentication & Authorization	optional	The Authentication & Authorization Pattern can be linked to this Pattern when this Pattern is to support authorization (and/or authentication), so as to feed the Traffic Filter facility with the results of identity and/or permission validations. By "permission validation" we also understand the execution of rules such as the well-known "firewall rules". Note that the rules that the Traffic Filter employs can be stored in a Permission Store within this Pattern, although most implementations of a Traffic Filter do not require Identity Validation/an Identity Store.

Pattern Variants based on this type

No Patterns Variants implement this Type (yet)