Traditional network security featured two or three zones, whether they were thought of in terms of zones or not may depend on the organization. Certainly everyone is failure with DMZ; however, modern approaches to network security don’t stop at the perimeter. This is where these new zones come in.
In the early days of network security, the consensus was: place a firewall at the external touch-points of your network with two or more network interfaces. If you ran any public services, locate them inside something called a DMZ or screened-network and restrict access to/from those devices for internal systems.
This should sound familiar, welcome to Network Zoning. The post-modern era of network security takes this DMZ approach and marries it with the principle of trust/privacy, so that the internal network can be carved up into segments providing increased security, compartmentalization, and privacy for users, services, servers, customers, etc.
In the earlier posts I referenced the idea of grouping like-functions of an internal network by vlan and/or IP subnet. This segmenting, grouping, partitioning, or zoning works just like the DMZ approach of traditional network security with the exception that the rules for access will be different and the “firewall” is internal. Here comes the tricky part.
Implementing the segmentation part can get complicated. I recommend vlans and different IP Address ranges as a general architectural practice, but it is possible with modern technology to insert transparent firewalls (let firewalls be firewalls) to facilitate rapid firewalling of network segments without having to implement vlans and IP Addresses.
These zones form boundaries inside the network, if you implement traditional firewalls they represent layer 3 boundaries and if you implement transparent firewalls they represent layer 2 boundaries. The outside boundaries should be thought of as untrusted, DMZ-like boundaries should be untrusted or semi-trusted, and depending on the user community the internal boundaries may be trusted.
These boundaries isolate trusted, untrusted, and semi-trusted devices and services from one-another and form what is referred to as a trust boundary. Trust boundaries can then be used to form privacy boundaries, where decisions are made segment trust implied within these various segments.
Getting back to the zoning concept, one design might feature an external firewall or set of firewalls (if redundancy is preferred) that provide the first barrier between the Internet and Internal users. Assuming the organization provides DNS, Email, Web, or other publicly available services, this firewall will provide an external DMZ as well. This will create one untrusted zone and one semi-trusted zone that will interface with an internal firewall/router acting as a semi-trusted barrier (zone) where the actual trusted zone(s) live.
The firewalls in this diagram can be routers, switch routers, firewalls, or a combination. The key is selecting hardware/software that will support the particular environment and needs of the organization. Firewalls come in all flavors, colors, and sizes these days and many do more than just filtering of packets, including deep packet inspection, IDS/IPS, load balancing, malware scanning, and web content filtering. Most routers on the market today can provide packet filtering / inspection in addition to traditional routing functions with minimal performance implications.
This specific architecture addresses minimal internal and external security from a zoning perspective needed to produce a trust barrier where internal systems should be protected from external (untrusted) systems. If the Internal Servers segment is firewalled from the Corporate LAN segment in this diagram, then four (4) security zones will form a privacy boundary in addition to the trust boundary where servers are isolated from users and outsiders are isolated from insiders.
I learned many things working for an former DOJ attorney but the thing that stands out the most is his savvy when it came to predicting what organizations would do in given situations. Legal regulations and contracts produce the same effect in businesses: do the minimum to get by aka comply.
Companies of all size grow and extend their business in order to satisfy their customers. If the company is publicly traded, then the company also seeks to please its stockholders. If security was a priority, companies would solve the data breach problem voluntarily. There are any number of reasons for security being what it is today.
We don’t need regulations in order to promote and achieve security within organizations, rather courage and leadership are needed. Security is not a profit-center, it is risk-avoidance; just like insurance. No one buys insurance (except maybe Allstate’s insurance) expecting to make money, insurance protects you against loss [whatever form that loss may take] but the insurance is only as good as the language in the policy. Security is no different; however, a company can reduce the cost and improve the effectiveness of security by including it throughout the organization and by building it into products and services instead of adding it on after a data breach has occurred. Unfortunately, too often security is implemented in the form of damage control following an incident because little financial justification can be made in advance of such an incident.
Regardless, politicians’ calls for “stronger” regulation are predictable because “stronger” regulation is “better”—in a press conference. In the real world, however, regulation is no more capable of divining threats to data security than, say, a common law liability regime, or even businesses’ natural interest in maintaining their operations, integrity, image, brand, and assets. [CATO]
Businesses will stay ahead of both the law and law breakers if strategy, business processes, and the big picture replace procedural band-aids, reactionary planning, and cost as their chief motivators. [ITCI]
If all that fails, you can still buy insurance!
I love the Terminator movies, Arnold is great in them. (No flames please!)
He apparently has some savvy advisers who have flexed their political and technical muscle in a way similar to Arnold’s physical: see Governor Kills California Data Protection Law. I find this line of logic amazing, especially given that Arnold is supposed to be some dumb jock elected Governor of California:
However, the current version of the bill, Schwarzenegger said, “attempts to legislate in an area where the marketplace has already assigned responsibilities and liabilities that provide for the protection of consumers. In addition, the Payment Card Industry has already established minimum data security standards when storing, processing, or transmitting credit or debit cardholder information.”
The governor argued that “the industry”—presumably a reference to credit card companies and the PCI Council—is in a better position to know what is realistic and reasonable for credit card security.” Also, he said, signing such a bill could actually create a conflict.
“This industry has the contractual ability to mandate the use of these standards, and is in a superior position to ensure that these standards keep up with changes in technology and the marketplace,” he said. “This measure creates the potential for California law to be in conflict with private sector data security standards.” —eWeek / Security Focus
I know security experts that couldn’t come up with the logic behind that statement. I’m not a fan of legislating everything and I think what the Payment Card Industry is doing with Data Security is great, if significantly late to the game.
The major problem I have with the PCI DSS requirements is the subjectiveness of assessment, audit, and enforcement. If the PCI DSS actually had teeth, then the breaches we read about would be less likely to occur because of the financial impact associated, For instance, when a merchant can’t process credit cards due to noncompliance with the PCI DSS, they would signficantly more interested in complying with PCI DSS.
George Gardiner wrote an editorial post on Oct 5th for IT Week noting the potential security / legal issues surrounding RIM’s Canadian-based data center that receives nearly all BlackBerry traffic to/from BlackBerry handhelds.
Having worked in the telecommunications industry, it came as no surprise that to learn that nearly all customers and carriers accessing or providing BlackBerry services are routed through RIM’s Canadian data center. George’s concerns centered around differences in privacy, security, and intercept laws between US, Canada, UK, EU, etc. (Original here, cached here)
This concern comes in stark contrast to the security and privacy offered by the BlackBerry handhelds. They almost all offer hardware-based 3DES encryption or AES encryption (AES is the current defacto), each handheld can encrypt ALL the content on the BlackBerry. Your data communications channel is encrypted back to RIM over your carrier’s network and your carrier likely has a dedicated data circuit connecting them directly to RIM’s data center.
The article suggests your data may be at additional exposure risk because it lives in a central point outside the control of your phone carrier’s control or your direct control and likely your country. Newsflash: Because your data is now in Canada it may not be as protected from interception as protections available in the US, UK, or EU. I read some interesting forum postings about the article, so I thought I’d pile on to the blog side of it.