Zero Trust, by Design

One of the best information security advice given on TV was by Fox Mulder’s dying informant, who told him, “Trust no one.” The subtle, yet profound quote easily made its way to t-shirts for X-Files fans and conspiracy theorists. Fast-forward roughly two decades, the t-shirts would be an ideal fit for a cybersecurity conference! Since the dawn of information security, trust has been a critical element. Even going back to the era of scrolls, the courier carrying the encrypted scroll was required to be a highly trusted individual. It was somewhat logical to carry forward this notion of trust to the computer information security world. The era of mainframes and monolithic software applications relied on centralization of processing and data, often limited to a single room. In a lot of cases, trusted individuals held the keys to physically gain access to computing power and data. Whoever had physical access to this perimeter, guarded by physical access controls (guards and locks!) also had unconditional access to the computing power and data.

As information technology architectures got more distributed, the notion of trust had to be stretched. Physical access had to be replaced or at least complemented by logical access. If you were on the corporate network; had a username and password; you could gain access to corporate information sources. Firewalls could prevent outsiders from entering the trusted zones. But then some business owners decided that they need nomad workers like salespersons or field engineers to have access to the corporate sources of information through the Internet. VPNs came to the rescue with trusted communication tunnels that could securely grant access to a trove of distributed enterprise data.

This patched up notion of trusted access seemed fine till the final explosion of distributed/mobile computing on one hand and adoption of cloud computing on the other side. Employees were soon using their mobile and personal computing devices (personal laptops, smartphones and tablets) to access the distributed data. The IT departments were no longer calling the shots on allowing access to corporate data only through sanctioned and company-issued computing devices. With the growing use of cloud applications (Salesforce, Office 365, Box, Evernote etc.), the IT departments were dealing with the proliferation of devices on one side, and further proliferation of corporate and sensitive data on the other; way beyond their reach. Marketing departments started using applications like DropBox or Box to upload their huge loads of media files to be shared with external media agencies for marketing campaigns. Product and research teams started using tools like Slack for collaboration on sometimes very sensitive initiatives. The use of such unsanctioned apps gave birth to the notion of Shadow IT. For quite some time now, IT has been fighting the BYOD and Shadow IT onslaught by outright blockage of traffic to unsanctioned applications or traffic from unsanctioned/unmanaged devices. But not only is the cost of this castle and moat approach becoming excessive; blocking access to new applications is almost akin to inhibiting innovation, today.

Zero Trust

With these external forces, the trust-based systems for protecting enterprise information are becoming obsolete. Meanwhile, the vector for insider threats to sensitive information continues to grow – not just because of malicious intent of insiders, but also advancements in social engineering to gain access to employee credentials. A notable state-sponsored attack in 2009 named Operation Aurora that compromised many large companies like Google and Akamai is attributed, partly, to social engineering techniques used by the perpetrators. The crux of orchestrating most social engineering attacks is phishing – pretending to be a trusted user or trusted system. Once a compromised user, device or application is able to enter a trusted zone, all hell breaks loose because the malicious actor can move laterally (east-west) in the network.

The Zero Trust Framework is a realization of this insider threat. Coined by the research firm Forrester Research, the concept of Zero Trust is simple – never trust, always verify! Not that people were not aware of insider threats prior to the introduction of the Zero Trust framework; it just helped giving impetus to an extremely crucial aspect of cybersecurity. The beauty of Zero Trust is not the novelty of the idea but the simplicity with which it (theoretically) weeds out insider threats. A user, device or any other resource that manages to enter the corporate network, and tries to gain access to sensitive/confidential data cannot and should not be trusted by default. And why would it! After all, the Internet is your new corporate network, which renders the notion of trusted network obsolete and impractical. The concept of Zero Trust is like a new credo for the IT security and cybersecurity teams – when thinking of security, no trust is the new default!

Implementing Zero Trust

Like other popular terms, Zero Trust has its share of “I’m Spartacus” or in this case “I’m Zero Trust” moments. Walk the floor of a cybersecurity or IT security conference, and you’ll quickly begin to realize that every technology on display claims to be a silver bullet to Zero Trust, if not Zero Trust itself! Zero Trust is neither a single product, nor a group of products. Zero Trust is merely a framework or a mindset – a mindset that reflects the realization of the new threat vectors arising because of the corporate data being stretched across an open cloud, and across a swarm of trusted and untrusted devices.

Mindset changes obviously require a lot more than technology bricks. But there are broadly two dominant (dominant, but not the 'only' ones) technology areas that would pop up in discussions of a Zero Trust framework – Identity & Access Management (IAM) and Network Micro-segmentation. Within IAM, Access Management requires a special mention in the context of Zero Trust. It is essentially a mechanism for granting access to a user to access a system or resource. A simple way to think about it is to imagine segregation of responsibilities between two different departments. Marketing reps only need access to the CRM applications, while accounting team only needs access to ERP; but both require access to a collaboration tool; and now, of course, many of these applications are in the cloud. Allowing granular access management for users, regardless of their location or device, is a critical feature for implementing a Zero Trust framework. Essentially, whether a user is accessing an application or data in the cloud or on-premises; from within the corporate network or from a coffee shop; the Access Management system must be able to enforce the appropriate security policies to grant access to that user.

Network segmentation has been an integral part of network security for ages now. And Zero Trust, in some ways is the anti-thesis of traditional network security. But network segmentation and micro-segmentation (not one and the same!) have become extremely granular today. A lot can be attributed to evolution in firewalls, switches and routers; but perhaps even more so to software-defined networking (SDN) and network function virtualization (NFV) that have allowed more flexibility and granularity in slicing and dicing the networks. In the same example above, a separate micro-segment can be defined for the Marketing department and a separate one for Finance, just so that they have access to their respective applications; and to minimize the threat of lateral movement of a malicious actor if an employee’s account is compromised (as shown in the illustration above). With micro-segmentation, potentially, each application (or workload) can be isolated in a way that it has its own firewall to secure it.

Both approaches are often pitted against each other. Interestingly, it’s not an either-or situation, as it’s often projected. In fact, while micro-segmentation reduces lateral movement of threats (often called east-west traffic) by isolation of resources, it still has to utilize an identity management mechanism to identify users, devices and other resources. From an architectural view-point, both approaches are different, but they are complementary in a lot of ways. In the longer run, most organizations are likely to use both approaches to achieve the objectives of a Zero Trust posture. It’s worth mentioning though that Google and Akamai (victims of Operation Aurora) both use a third approach to achieve Zero Trust, which makes use of an Identity-aware Proxy. Here’s a great blog post if you want a comparison of these approaches/architectures.

Security by Design

Security by Design is a security paradigm used in software and (increasingly) hardware systems development. The crux of security by design principle is to make systems secure ground-up, using processes, tools and technical bricks in a way that the system is secure from its design to its deployment. The concept is especially useful for envisioning security in the context of modern day proliferation of devices, both mobile and IoT. Seemingly counter-intuitive, with so many parties involved in the value chain for delivering today’s systems, going to source or root of each component (hardware, software or data) is a critical aspect of security by design. Rapid adoption of DevOps has eluded to the impression that cloud-native applications are truly secure by design. Interestingly, till just a few years ago, one of the biggest inhibitors to cloud adoption was, in fact, security (or perceived lack of)! And today, being cloud-native is somewhat symbolic of a more secure posture. While the jury is still out, there is no doubt that the modern automated controls are far superior and DevOps-friendly for building secure applications, ground up. One thing that hasn’t changed much in the transition from on-premises to on-cloud is the need for a hardware root of trust (HRoT), a concept that forms the backbone of secure systems. Building secure products, ground-up, requires a strong reliance on a root of trust. If a user wants to enter a secure facility, she’s most likely using some type of a security badge (smart card) to gain access. In the logical access world (logging into your PC or gaining access to applications), tokens like USB dongles, smart cards or OTP tokens are still considered the most secure way of gaining access to sensitive data. The same principles apply to developers and engineers when they have to gain access to sensitive source code for building secure applications. Similarly, the sensitive data itself, whether at rest or in motion, relies on a hardware root of trust like an HSM (Hardware Security Module) to ensure that it is encrypted. Whether you consider the most sensitive information like SWIFT transactions; a trove of sensitive data residing on cloud infrastructures; or software developers using code signing to deploy sensitive code, chances are that there is an HSM being used as a root of trust to ensure such sensitive data remains confidential, and that its integrity can be guaranteed.

Zero Trust, by Design

In the Digital Identity & Security space, we see a very large number of customers moving their workloads to the cloud, with an ever-increasing appetite for more IoT devices in their ecosystems. Whether these customers are aware of the Zero Trust or Security by Design principles or not, they seem very aware of the security threats that follow with the adoption of the cloud, mobility and IoT. Addressing these security challenges becomes more daunting when dealing with an IT (and Shadow IT) infrastructure that involves a multi-cloud environment with an increasing number of untrusted endpoints.

A way to address this rather expansive threat surface is to work on a Zero Trust principle, while ensuring that security is baked into every product and service by design – whereby achieving Zero Trust, by Design

As paradoxical as it may sound, a way to address this rather expansive threat surface is to work on a Zero Trust principle, while ensuring that security is baked into every product and service by design – whereby achieving Zero Trust, by Design. The paradox here is how, with the IT perimeter expanding on one side, should a CISO ensure security that is grounded with a hardware root of trust. One solution is how Google implemented it in its BeyondCorp implementation – relentlessly tight control. For example, Google uses managed devices (devices that have been sourced and maintained by Google); to which it issues certificates that are stored on a Trusted Platform Module (TPM) as its root of trust. This ensures a very tight control even before the device latches on to the Google network. Similarly, for users who want to access company resources, Google makes use of a hardware-based token/key that utilizes a proprietary firmware, making their security almost impenetrable.

Nothing wrong with the approach, except that it’s hard to replicate for many other organizations. TPMs and hardware tokens have been in use for many years now. But the technical maturity of most organizations varies significantly. Implementing such a tightly regulated IT infrastructure, where even the web browser is limited to a single brand, may actually increase the friction for the users. Most organizations will have a hybrid and multi-cloud environment with a lot of legacy infrastructure that is almost impossible to just rip and replace. In order to employ security by design without compromising user experience, organizations require flexible security solutions that are resilient and built for a multi- and hybrid-cloud environment.

Implementing Zero Trust by Design

A lot of enterprises that we speak to today are caught in this dilemma. There is a growing awareness of the Zero Trust paradigm. But organizations want the flexibility to choose an approach that best suits their IT and organizational readiness – ramping up at a pace that fits their needs. If network micro-segmentation is the way forward, aside from the conventional HSM-based data protection; customers now have a choice to deploy cloud-based data protection capabilities like HSM-as-a-Service or BYOK or KMS-as-a-service, to name a few. These capabilities not only enable network security vendors to offer greater flexibility and lower the TCO for the end customer in the SDX (Software-defined Everything) era, but also matches high levels of security based on a hardware root of trust. Cloud-based data protection also transcends into areas like privileged access management (PAM) and cloud access security brokers (CASB); PAM being a critical requirement for compliance in highly regulated markets, and CASB being a critical stepping stone in cloud security for organizations moving their workloads to the cloud. These modern-day data protection solutions also give impetus to the overall DevOps capabilities to transition to DevSecOps – critical to achieving Security by Design in a fast-evolving world of APIs, microservices, containers and what not!

If the organization decides to take an identity-centric approach to implement Zero Trust, a broad range of multi-factor authentication (MFA) tokens is imperative to address the root of trust issue for users. Whether for employees or partners, MFA can really reduce the phishing and insider threat, especially when a hardware token is used. On the flip side, users may range from high-privilege users like system administrators or CxOs to PoS staff that seldom requires access to highly sensitive applications. Opting for a broader range of MFA support can really ease the adoption, while ensuring that a root of trust is inherent to the design of a Zero Trust architecture. Like users, corporate devices can make use of TPMs in conjunction with PKI to issue strong identities for corporate devices.

One final area that requires attention is addressing the Internet of Things. IoT security is a different ballgame all together, especially when dealing with connected critical infrastructure. The complexity of the supply chain makes it extremely hard to address the root of trust problem. Enterprises that want to extend security by design to their IoT devices can use secure elements in conjunction with scalable credential lifecycle management to address the complexities. I recommend reading some of my previous posts on this topic for understanding the need for credential management in IoT.

Achieving a balance between a high security assurance and user convenience has been, and still is the epicenter of the modern-day CIO or CISO’s responsibilities. With regulations like GDPR, the race to Zero Trust (if there’s such a thing!) is not just a good-to-have, but a must-have. The Fox Mulder paranoia is perhaps not a bad start, provided it balances the security controls with business needs. Both Zero Trust and Security by Design are fairly old concepts, but extremely crucial to ensure that modern IT infrastructures are built ground-up with security in mind; and used/operated with a perimeter-less mindset of Zero Trust. Trust no one, always verify!

DISCLAIMER:?All the cool views presented in this post are my own, and do not necessarily reflect the views of my past or present employers.