The shift of security architecture to a data-centric model versus a network access-centric model confuses the method in which we have continued to approach securing the network perimeter. We have marched to the same wisdom of a DMZ sandwiched between firewalls or now the same firewall with multiple interfaces. This network design addresses network connectivity and is non-important for real data protection. While it is true, the basic low skill attacks will be stopped, but we have seen that this design does not thwart even the semi-sophisticated attack methods. The reason is because the data is not protected, but the network perimeter is.
While it is important to protect the network and implement segmentation via firewalls, we cannot stop here to protect our network assets. If we approach the systems as storage for data, we can overlay our trust models to enforce authorized access methods that can be much more agile than the typical DMZ, business partner zone, or remote access network architecture. Do you recall the section in Chapter 2, Security Architectures, where I suggested that security architecture has been robbed of its individuality by basically working only within the confines of network architecture? Security architecture is a distinctly different practice with differing rationale and therefore needs to be aware of the network design, but the network is merely transport; let's not elevate it to be the primary defender of our network and assets.
Typically, the DMZ access is tightly restricted for inbound connections; however, outbound connections can be a little more lax. This is because from the network architecture perspective, traffic leaves and does not pose the risk of a possible inbound attack. From a security perspective, the concern may be more about what is leaving than what is coming in, after all, a firewall and IPS protect the majority of the inbound network at the perimeter.
Firewall policy, however, does leverage security architecture if closely examined. An example is HTTP connections inbound to a web server. First, the firewall rule typically will have an "any" as the source; this is an untrusted source, per our trust models. The second configuration will be a specific destination or set of destinations that represent the web servers, and lastly the specific TCP port 80 or application HTTP will be defined. Some of what is configured at the network perimeter is inherently security architecture defined in network security appliances.
To take this a step further, let's apply this same logic to each host in the DMZ. Applying trust models at the host and services tiers is where most security-based network architectures end their application. Flexibility is lost when agile security architecture is not applied. Several instances of the same application may be stood up to support different user groups, just because the systems have to reside in certain portions of the network, based solely on the user of the system. In this case, defining all user types for the known data and applications will form the basis for the trust models to be applied; there will be a model for each user type defined.
The internal network should technically not be treated any different than a DMZ from the security architecture perspective. Just because a host is on the internal network does not vouch for its trustworthiness. From my experience, the internal network is still soft and an extremely vulnerable portion of the network that gets little attention. I am not stating that the internal network has to be locked down like Fort Knox; only if proper network segmentation does not exist and a proper perspective of risk exists based on an analysis.
Internal network hosts should be treated as trusted as they can be, depending on what controls are implemented on the hosts themselves. The key to internal network security architecture is enforcement and monitoring. The initial implementation will be very clean, but over time, things get messy and, before you know it, the user groups on systems are a mess. All the restrictions and controls in place serve as nothing more than a management nightmare with no security value being realized.
This is found more on the internal network, because enterprises have a somewhat blind trust for all things on the internal network, yet we find breaches occurring through data exfiltration due to misconfiguration of security controls on internal hosts. Security must be applied uniformly to have the intended impact of securing the enterprise.
Internal network segmentation using a firewall (only real segmentation; VLANs don't count, sorry) is a mix of the DMZ and internal network implementation of the security architecture. One significant use of internally segmented networks is that we can terminate business partner and other third-party access to services and various assets. The purpose behind this method is to limit the scope of compromise so long as the network communications are restrictive for both inbound and outbound directions.
There are some compliance standards that offer audit scope reduction through segmenting certain environments from the internal network, such as PCI DSS's recommendation to segment the cardholder data network. Other great resources that cover best practices for network security include NIST 800 series Publications, SANS Consensus Audit Guidelines, and the ISO 27001/2 standards.
The internal segment may have web, application, and database tiers much like a DMZ for critical internal business processes accessible to internal and other third-parties. The flexibility of our presented security architecture would only differentiate these user types by access level, maybe. This is the benefit of the trust model based security architecture. It doesn't matter much where the asset resides, who or what is accessing the asset, as long as there is a standard method to implement the security architecture.