PAT.Data Zone Protection
|PAT||Data Zone Protection||Version:||0.2|
|Document type:||Pattern Type||Owner:|
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.
This is the graphical representation of the infrastructure functions in this Pattern Type, plus their main relations:
Pattern Type Composition
This pattern has the following mandatory and optional subfunctions, expressed in Building Block Types:
|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:
|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)