Looking back through the years, I want to start by talking about the most important events in the history of the secure network architecture design.
In 1993, there was the launch of Stateful Inspection Firewall technology, created by CheckPoint, who led the market for several years. Its evolution leveraged the development of secure network architecture initiatives, including a new service in security consulting: the design of secure network architecture.
The first network architectures I designed were oriented to segment the network, and provide an access control system that connected all network segments and included authentication and authorization systems for access to sensitive applications and data. It also deployed network-level auditing capabilities on key segments through IDS systems and obtained system logs. Cryptography was critical, but we only used it for traffic carried on insecure networks, i.e., those that were not within our perimeter.
In 2010, the concept of eliminating the perimeter was integrated, which led to altering architectures, including elements that helped validate remote access controls, strong authentication, anomaly analysis and context to improve access to the organization's internal network. Those accesses were provided with a pool of addresses from which network resources could be accessed in accordance with established internal controls.
And finally in 2016, changes were evidenced because the resources were no longer in our control and organizations began to consume third-party services and in the cloud, which consequently transformed the vision of security as the protection of a medieval castle, including multiple layers of control to minimize risks.
The current challenges of network architecture
Today, organizations have transformed or are in the process of transforming. They have stopped keeping data on their premises and have started to use services and solutions that help them to be agile and to automate as much as possible their interactions between their customers and the delivery of products and services.
This has evolved the security assumptions and controls used to protect the organization's resources (applications, systems and data). The following is a list of controls and their evolution to the new secure network architectures.
Protection |
Original Control |
Real control |
Network Access Control System |
Firewall Statefull Inspection |
Firewall as a Service |
Authentication and Authorization System |
AAA (Active Directory, Radius, Diameter), PKI |
Authentication and federation based on risk, ID |
Cyber Security Event and Incident Analysis |
SIEM |
Security Analytics (SIEM, UEBA) |
Network Threat Analysis |
Intrusion Detection/Prevention Systems IDS/IPS |
Network Detection & Response (NDR) |
Endpoint Protection |
Antivirus |
EndPoint Detection & Response (EDR) |
Cifrado de Datos en Tránsito |
VPN/SSL |
Software Defined Perimeter (SDP) - TLS |
Threat Context and Security Intelligence |
Intelligence Sources per Security Provider, HoneyPots |
Threat Intelligence System, Deception System |
Security Diagnostics and Compliance Systems |
HIDS, FIM |
CDM System |
Zero Trust Architecture (ZTA)
Zero Trust Architecture (ZTA) applies a set of controls in order to ensure that the analyzed traffic has the same level of trust. The trust zone should be as small as possible.
Its implementation is based on the following principles (information extracted from NIST SP 800-207):
- All data sources and IT services are considered as assets.
- All communications are secured, regardless of their location in the network.
- Access to the organization's resources is granted on a per-session basis.
- Access to resources is determined by a dynamic policy and should include other attributes such as behavior and context.
- The organization monitors and measures the integrity and security posture of all owned and associated assets.
- All resources must have dynamic authentication and authorization before access is granted.
- The company collects as much information as possible on the current state of assets, network infrastructure and communications and uses it to improve the security posture.
Although these are basic security principles, the Zero Trust architecture does not take into account several of them that guarantee a robust architecture (see ISF security architecture).
The Risks of ZTA
Some critical ZTA risks are outlined in the NIST Special Publication and are listed below:
- ZTA Decision Process Version Control.
Control models are classified as discretionary, role-based, and mandatory. The most secure is the mandatory model, but it is the least agile, conversely we have the discretionary model, the least secure but most agile.
The ZTA model and most current firewalls are based on discretionary models. The ZTA model does not change and exposes the company to the same risk caused by misconfigured policies.
- Denial of Service (DoS) or network component failure
Administration and Policy Engine systems become key elements of the architecture. Any failure can result in the loss of access to all network resources.
- Credential ID Theft / Insider Threat
The ZTA does not effectively address today's most critical risk of secure network architectures and that is identity theft. Because this type of architecture relies on authentication and authorization; phishing, social engineering or a combination of these two attacks target key accounts to gain access to trusted zones.
- Network Visibility
Infrastructure has limits and security solutions do not always have the capacity to perform deep packet inspection of all network communications. It is often not feasible to examine encrypted traffic, so many attacks can go undetected.
- Safeguarding of systems and network information
All sensitive network and system configuration information must be protected from unauthorized access. This information can help to clearly understand how to circumvent ATZ controls.
- Support in proprietary solutions or data structures
ATZ is supported in different data sources to make decisions, however, if you do not have a standard you may have interoperability problems.
- Use of Non Person Entities (NPE) in ZTA administration
Connecting services can affect the policy with false positives and negatives impacting the security posture of the organization.
A robust network architecture
The ZTA contains the evolved secure network principles but leaves out other key elements and fails to take into account many learnings that have been gained with respect to technology and security controls capabilities.
The first element where the Zero Trust model fails is that it relies entirely on the Policy Decision/Enforcement Point (PDP/PEP). Trust is a key element of being human and security cannot go against our own nature.
The elements that are part of the security principles and are not included are:
- Defense in depth
- Security by design
- Safety in failure
- Simplicity
The second element, DataDriven Security, is fundamental in a robust architecture. The ZTA takes it into account as a source of external information that helps decision making and not as the core of the architecture.
Finally, all prevention is supported by the PDP/PEP, ignoring the fact that the need to respond and prevent is present in all resources and systems that are part of our network architecture, what we now call adaptive network architecture.
The design of secure network architectures has evolved over the years. Today, organizations are betting on cloud services and solutions that help them to be agile and automate as much as possible their interactions between their customers and the delivery of products and services. This has led to the evolution of security assumptions and controls to protect resources.
Although the Zero Trust architecture applies a set of controls to ensure that the analyzed traffic has the same level of trust, it does not include some security principles, which does not guarantee a robust architecture and leads to experience critical risks within organizations.