Introduction

Zero trust is a philosophy and a related architecture to implement this no trusted way of thinking founded by John Kindervag in 2010. The principle is to never trust anything by default, therefore every access request should be authenticated and authorized as if it originates from an open network.

“A journey of a thousand miles begins with a single step.” Lao Tzu

While Zero Trust Cloud Security might seem formidable, there is plenty of help around. This article attempts to take one through a history tour of Zero Trust Security and discusses salient issues to help you plan your Zero Trust journey in a systematic and risk mitigated manner.

US President, Ronald Reagan when dealing with Russians quipped “Trust but verify”. This has been hailed in the business lexicon for years. The simplest and the pithiest way to capture Zero Trust is the opposite of this “Never Trust.. Always Verify”.

Zero Trust – Old wine in a new bottle?

Is Zero Trust – old wine in a new bottle??… well.. quite possibly…almost… The following shows the progression of the basic concepts underlying Zero Trust.

Prof Saltzer (MIT, the inventor of the Multics operating system progenitor to UNIX) is clearly the birthing father of the Zero Trust concept. He termed it “Least Privilege” and defined it as:

Every program and every user of the system should operate using the least set of privileges necessary to complete the job.

Brilliant inventors from the 2 US coasts: MIT (RSA: Rivest Shamir Adelman) and SRI (Prof Martin Helman and Witfield Diffie), stalwarts of the security industry as we know it today, invented the PKI (Public Key Infrastructure).

A public key infrastructure (PKI) is a set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking, and confidential email. It is required for activities where simple passwords are an inadequate authentication method and the more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

We owe modern-day secure internet to HTTPS, which is based on SSL which in turn is anchored on PKI.

Ken Thompson, developed MULTICS further and is one of the fathers of modern-day UNIX when he was at AT&T Bell Labs. In his Turing award paper, he discussed the reliability of computer programs and discussed mechanisms to ensure that they will not generate malicious activity.

Lines of code ken Thompson

RFC 1636 (Hard Shell.. Soft and Chewy Center) discussed the idea of having a very dense perimeter and a relatively permissive interior as a mechanism for strong security. The ideas outlined there formed the basis of modern-day perimeter security.

Jericho Forum was initiated by UK Royal Mail and outlined core principles that serve as the underpinnings of modern-day Zero Trust Security.

Fundamentals

• The scope and level of protection should be specific and appropriate to the asset at risk.
• Security mechanisms must be pervasive, simple, scalable, and easy to manage.
• Assume context at your peril.

Surviving in a Hostile World

• Devices and applications must communicate using open, secure protocols.
• All devices must be capable of maintaining their security policy on an un-trusted network.

The Need for Trust

• All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place.
• Mutual trust assurance levels must be determinable.
• Identity, Management, and Federation
• Authentication, authorization, and accountability must interoperate/exchange outside of your locus/area of control.

Access to Data

• Access to data should be controlled by the security attributes of the data itself.
• Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges.
• By default, data must be appropriately secured when stored, in transit, and in use.

This is the first time the term “de-parametrization” was introduced.

John Kindervag, in 2010, coined the term Zero Trust. As one can see, the concept of Least Privilege, the basic element of Kindervag’s Zero Trust definition has been around for the prior 35 years. However, Kindervag deserves immense credit for coming up with a very crisp and succinct definition and this led to its widespread acceptance.

The following are Kindervag’s Zero Trust tenets

1. The network is always assumed to be hostile

2. Assume threat actors are already inside your network

3. Network locality (segmentation) is not sufficient for deciding trust in a network

4. Every device, user, and network flow is authenticated and authorized

5. Policies must be dynamic and calculated from as many sources of data as possible

6. The device is no longer the border.  A user/service’ identity is the net border

7. Containers, serverless, and cloud are the new disruptors of traditional security architecture

As Einstein said, “Everything should be made as simple as possible, but not simpler”. Kindervag’s definition of Zero Trust fits this definition to the tee.

Around 2011, Google promulgated its Zero Trust variant, BeyondCorp. Furthermore, Google played a pioneering role in spreading awareness of Zero Trust in the industry. BeyondCorp embodies the following principles:

1. Access to services must not be determined by the network from which you connect.

2. Access to services is granted based on contextual factors from the user and their device.

3. Access to services must be authenticated, authorized, and encrypted

BeyondCorp was mainly focused on Enterprise Campus Networks.  More recently, Google has played a pivotal role in furthering these concepts to the Cloud. This has been formulated under the moniker, BeyondProd, and focuses on the core of Cloud Asset Security.

“Just as a perimeter security model no longer works for end users, it also no longer works for microservices. Protection must extend to “how code is changed and how user data in microservices is accessed.”

The SolarWinds attack was literally a “bolt from the blue” and major US organizations were caught off guard. CISO Sentiments were rightfully somber as discussed in a CISO Magazine in Jan 2021:

• The impact of the breach is profound. It really turned on its head a lot of conventions about cyber security. We are now in a situation where we have to monitor the monitors
• The attack did not have any signatures of a previous attack. So you got down to the code level
• 80-90% of code is being downloaded from the internet.. It is bringing DevOps security processes to their knees and making us rethink how to reinvent security

Given the SolarWinds attacks, The US Government has taken a decisive leadership as outlined by the following initiatives:

1. US Government, Cybersecurity and Infrastructure Security Agency (CISA) issued Emergency Directive to Mitigate Threat from SolarWinds Orion Network

2. The Cybersecurity and Infrastructure Security Agency (CISA) issued Emergency Directive 21-01, in response to a known compromise involving SolarWinds Orion products that are currently being exploited by malicious actors. The Emergency Directive calls on all US federal civilian agencies to review their networks for indicators of compromise and disconnect or power down SolarWinds Orion products immediately.

3. “The compromise of SolarWinds’ Orion Network Management Products poses unacceptable risks to the security of federal networks,” said CISA Acting Director Brandon Wales. “Tonight’s directive is intended to mitigate potential compromises within federal civilian networks, and we urge all our partners—in the public and private sectors—to assess their exposure to this compromise and to secure their networks against any exploitation.”

4. Implement recommended mitigations as soon as possible.

Furthermore, the US Department of Defense [DoD] and several key agencies (NSA, NIST,  etc.) have made Zero Trust security a mandate for companies, governments, and non-profits. This is depicted by the following initiatives.

Furthermore, The Office of Management and Budget (OMB) and the Cybersecurity and Infrastructure Security Agency (CISA) [1] have produced technical guidance documents in their endeavor to help the U.S. government towards a Zero Trust architecture.

Despite the immense benefits of ZeroTrust Security solutions, they have been hard to implement and deploy at scale. This and related issues were discussed at the ZeroTrust DevSecOps NIST Conference [2].

Given that we have covered a fair bit of ground on the What, and Why of Zero Trust Security, it would be appropriate to discuss Zero Trust Cloud Security,

Why Cloud?

The logic and rationale of migrating to the Cloud should be apparent. At the risk of re-stating the obvious, the key reasons include:

• Developer productivity – All the cloud providers provide a vast plethora of development languages, databases, packaged business applications, libraries, AI/ML models so developers can be up to speed in a relatively short time frame.
• Fixed vs Variable Cost – Unlike Data Center assets which involve considerable fixed costs, Cloud Platforms make the pricing variable elastic. Since Cloud Compute assets come at a steep cost,  most firms use a combination and hence the apt expression “Own the base. Rent the burst”
• Talent shortage – Given the vast developer ecosystems and certified personnel that the major cloud platforms offer, in the current world of talent shortage, it is far more efficient to tap into this talent ecosystem.

Why Microservices? Why Kubernetes?

Micro-services ensure that all the cloud assets (compute, network, storage, applications) are used in the most optimal manner and one does not incur the cost of idle assets. Furthermore, Kubernetes (which was initiated by Google) has established itself as the most Open and Efficient framework for orchestrating micro-services due to the following inherent benefits:

• Resiliency – self-healing
• Adaptability
• Automation
• Auto-scaling
• Standards-based Abstraction layer

However, micro-services are a highly ephemeral and transient nature.

Hence, securing Kubernetes, especially at run-time remains a challenge. This has resulted in a number of highly publicized attacks

Since IP addresses are ephemeral, they are not valid predicates to protect containers. Hence, this requires a new paradigm, one that involves identities (user and service): cryptographically signed X.509 certificates or JWT tokens. Hence the expression “identity is the new perimeter”

What is DevSecOps?

noun [dev-sek-ops]

Short for development, security, and operations, this model automates the integration of security at every phase of the software development lifecycle, from initial design through integration, testing, deployment, and software delivery.

Why is DevSecOps important?

Developers are focused on delivering functionality to meet the goals of the business. Delivering functionality at the agility and velocity of the business requires a CI / CD (Continuous Development / Continuous Integration) approach and does not allow for issues to be detected at late stages in the development cycle. Often, security departments discover issues precisely at this late stage, placing developers at loggerheads with the security goals of an organization.

Developers worry about delivering (in Steve Jobs’ words) “insanely great products:

• Great user experience
• Great APIs that can be consumed by other developers, etc.

However, for this to be deployable, maintainable, monitorable and secure, the following key questions need to be addressed:

• What are the rate-limiting parameters?
• Does it have guardrails against Denial of Service attacks?
• Does it meet corporate authentication standards?
• How is it secured?
• What compliance, governance frameworks does it need to meet?
• Does it support the most comprehensive set of security controls and counter-measures?
• Does this implement “least privilege” Zero Trust principles?

While it is always a shared responsibility, it is imperative that Security Products and Tools do not burden the developer with implementing security, security policies; and endeavor to provide tools, harnesses to make it easy for developers to ensure that their software is secure by default. While this might seem like a tall goal, we have an “existence proof” – SSL libraries helped web/browser communications secure by design, default. DevSecOps aims to do the same at a larger scale for Enterprise Applications by baking in security as default, removing the burden of security away from developers.

NIST Guidelines for Zero Trust Microservices Security

As it pertains to micro-services, NIST IR 8313 offers the following guidelines for ZeroTrust:

• Ability to authenticate application user credentials
• An authenticatable runtime identity for services
• Encryption of “in transit” communication between services
• A Policy Enforcement Point (PEP) is separately deployable and controllable from the application
• Logs and metrics for monitoring policy enforcement

ZeroTrust delivered in a DevSecOps model

AccuKnox enables DevSecOps for the Microservices in the Cloud by providing tools, frameworks, integrations at every stage. This is illustrated below:

It is further elaborated in the table below:

The following outlines the set of Static and Run-time Security controls that needs to be implemented to ensure Zero Trust Cloud Security.

AccuKnox blog 2021 Cloud Security Review outlines several well-publicized cyber attacks in the Cloud. In all these instances, the said organizations had basic Static Container security. While static security tools are necessary they are not sufficient to address advanced attacks like the ones covered in the blog and the most recent Log4J, which we have discussed in this blog.

Summary

Our connected ecosystem increases the attack surface to millions, billions, trillions. While the connected world has done marvels for society, the recent SolarWinds attack and the cascade effect that ensued demonstrated the shared risk we face and the fact that we are only as strong as the weakest system in our connected ecosystem. While we can never 100% prevent the initial attack, early detection, and blast radius containment are very reasonable and achievable goals. ZeroTrust solutions make it easy for organizations to achieve this. Further innovations by AccuKnox and others to facilitate deploying ZeroTrust solutions in a DevSecOps fashion make it easier for developers to embrace it and organizations to adopt it. Zero Trust is more about Resilience than Protection and hence the following, derived from President Ronald Reagan’s famous quip “Trust but verify” is apt for the Zero Trust world we are entering.

Author

Nat Natraj is the co-founder/CEO of AccuKnox. AccuKnox provides a Zero Trust Run-time Kubernetes Security platform. AccuKnox was founded in partnership with SRI and is anchored on SRI’s seminal inventions in the areas of Container Security, Anomaly Detection, and Data Provenance. AccuKnox can be deployed in Public and Private Cloud environments.

Natraj can be reached at [email protected](@N_SiliconValley)

Visit www.accuknox.com or follow us on Twitter (@accuknox)

---

References

[1]  US Department of Defense – Zero Trust Reference Architecture

[2]  NIST – Zero Trust Architecture

[3]  DevSecOps and ZeroTrust – NIST Seminar

[4]  Ken Thompson – Reflections on Trusting Trust

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]