PAT.Data Zone Protection

From OIAr Archive 2013
Revision as of 16:01, 16 January 2013 by Jan Schoonderbeek (talk | contribs) (link fix)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Page maturity
This page has maturity level 3 (usable)

This is a Pattern document

Document icon PAT Data Zone Protection Version: 0.2 OIAr logo
Document type: Pattern Type Owner:

J.A.H. Schoonderbeek

Create commentary


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:

Protected Link graphic

Framed Pattern Type legend.png

(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
BT.Traffic Filtering icon 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.
BT.Data Scanning icon 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).
BT.Control Interface icon 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.
BT.Distribution icon 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.
BT.Load Balancing icon 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.
Facilities Monitoring 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 (a Security instance of) Facilities Monitoring.
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)