A tale of two enterprise security architectures — replacing a derelict castle-and-moat with the Zero Trust method and how the cloud got there first

The common theme with data breaches is how access was gained to one part of a network that enabled the attacker to extract the critical data from another part of the network. The perimeter defences had been thwarted and before the alarm bells could ring, millions of records containing personal data were being sold on the dark web. But why was this so easy? Surely gaining access to one desktop machine shouldn’t lead to accessing the organisation’s most sensitive data? The failure here comes down to trust, or most specifically the unnecessary amounts of trust bestowed on the internal network.

The solution to this has been around for some time and it is called the Zero Trust network architecture, which was first promoted by John Kindervag in a Forrester report in 2010[1]. While the new architectural design was well received, it didn’t align very well with selling the current product lines of firewalls or routers that formed the basis for most enterprise networks and so the traditional perimeter based security architecture remained.

When the world of enterprise IT was a more simple story — before the adoption of cloud services and before the workforce used an assortment of devices to tap into enterprise services 24/7 from any location — the idea of trust on the network was binary. We trust what is happening inside our network and don’t trust anything coming from outside.

The major flaw with this model is that once a bad actor is inside your network they have the ability to move around and access information assets with very few barriers to prevent them inflicting damage.

Nearly a decade later, enterprises are becoming all too aware of the risks associated with their reliance on a perimeter network security model. This old world thinking was limited by the technology and tools that were available. The use of firewalls and routers allowed an enterprise network to be segmented into zones. The typical model would identify an Untrusted/ Internet zone, a Demilitarised Zone (DMZ), a Trusted/Internal zone and, depending on the type of data being handled, a Restricted zone for more sensitive information assets.

You might already be using Zero Trust without realising it

Zero Trust is based on three core principles:

1) All resources are accessed in a secure manner regardless of location

2) Adopt a least-privileged strategy and strictly enforce access control

3) Inspect and log all traffic — from any source to any destination

Zero Trust is now made possible through the application of Microsegmentation, Multi-Factor Authentication, Identity and Access Management (IAM), orchestration, automation, log and packet analytics, encryption and Virtual Network Functions(VNF). If you are at the beginning of a digital transformation project or you’re building an enterprise security architecture from scratch, you are likely to be applying these technologies to your program design. You may also find you’re working with these concepts through the use of one of the leading cloud platforms from Amazon, Microsoft, IBM or Google.

In Amazon Web Services (AWS) we find the notion of Security Groups running throughout the platform. This works as a form of Microsegmentation and is implemented through a whitelist design, allowing the approved network traffic through to a resource while all other traffic is blocked. Another benefit from this implementation is that it has no reliance on a hierarchy or priorities, which are commonly found in firewalls or routers, and lead to rules being negated by conflicting priorities. The effectiveness of Security Groups can be extended further with resource policies. Allowing the granular rights to be defined in accordance with an asset or set of resources.

Microsoft has provided similar support across its cloud platform, Azure. Some notable differences are in their acceptance of both whitelist and blacklist rules in their Network Security Groups (NSG) that require the configuration of priorities to ensure the rules are carried out in the right order. Additionally, Azure provides two separate deployment models: Classic and Resource Manager. Simply put, the Classic mode limits the policies to the instance, equivalent to a virtual machine, while Resource Manager mode takes them down to the network interface controller. The latter is more inline with the implementation found in AWS.

IBM Cloud offers an extensive range of options, allowing the definition of Software Defined Networks (SD-WAN), controls over Virtual Network Functions (VNF) that meet the capabilities of AWS’s Security Groups, resource policies and potentially more. In addition there is Activity Tracking that is more extensive in its depth of coverage than the competitors equivalent offering where a third party solution would be necessary to perform the same function. There is also support for more traditional network security technologies with dedicated hardware firewalls allowing the existing network security to be extended into the cloud more seamlessly — although this may also allow for lapses in the design.

Google knows first hand how not applying all the core principles of a Zero Trust architecture can leave a weakness in your defence. After Edward Snowden leaked how the NSA was able to tap into the internal networks of Google[2]. Google took immediate steps to resolve this unauthorised use of data in transit and implemented an architecture that was later detailed and released in a research paper called BeyondCorp[3]. In this paper they describe how in 2014 they implemented a Zero Trust network inside Google. Rather than treating the outside as untrusted, Google now treats all networks as untrusted. At all points data is encrypted, users activity on their regular devices is recorded as a recognisable pairing so exceptions can be appropriately treated as suspicious.

With this experience no doubt feeding into their designs, Google has released security features to its Google Cloud Platform (GCP) with the aim of leading the way in security from the other cloud platform providers. Google has implemented a design that enables security at the application level. This includes granular access management, enforced strong authentication mechanisms and key management. One stand out capability that is not found in other cloud platforms is a Data Leak Prevention (DLP) API. This allows data being provided by applications to be monitored against administrator defined rules for improved security and conformity to stringent data privacy regulations.

How to get from A to Zero

This all sounds great unless you’re a CISO/CIO responsible for managing an existing security architecture with a tight budget. There are however steps that can be taken to implement a Zero Trust architecture gradually.

Ensuring that all new services enforce authentication, that data is encrypted in transit and at rest will help reshape the organisation’s mindset. This is also an easier starting point then retrofitting to existing services and assets.

Where some budget is available, securing the most critical information assets gains a logical priority. The consensus is that Zero Trust is going to protect these assets more effectively by ensuring that only network activity that is authenticated and approved by design gains access. To accomplish this it’s necessary to be able to identify all the traffic first. Only once this is achieved can the granular controls be applied.

Before this strategy can be put into motion, there is a need to build awareness amongst the software, network and security teams on how to implement a Zero Trust network architecture for the implementation to be successful. Embedding security engineers into key phases of software development projects will also aide the effectiveness of your Zero Trust implementation. The old castle-and-moat mentality is second nature to most and the mindset for some will be difficult to change.

With virtualised environments, consider Microsegmentation as a significant step towards a Zero Trust architecture[4]. Virtualisation platforms, such as VMware’s NSX platform as well as network virtualisation technology from Cisco, Juniper Networks and Nuage will support Microsegmentation. This allows more granular control around access to applications and the network’s shared resources.

As well as educating teams about implementing a Zero Trust network it is also important to learn how to manage this new methodology once it is up and running. With more granular rules and configuration there will be additional maintenance and management to ensure it remains effective. Utilising advanced DevOps tools to automate environment configurations and apply governance controls to deployments will help limit the impact of this while maintaining the designed Zero Trust model as it was intended.

[1] http://www.virtualstarmedia.com/…/Forrester_zero_trust_DNA

[2] https://www.theguardian.com/…/google-reports-nsa-intercepts-data

[3] https://research.google.com/pubs/pub43231.html

[4] https://www.sdxcentral.com/…/how-does-micro-segmentation-help