+
+ |
+ |
+ Tenet
+ |
+ Cloud Native Principle
+ |
+
+
+ | 1
+ |
+ Assume a Breach
+ |
+ Every Image Includes Vulnerabilities
+ |
+
+
+ | 2
+ |
+ Assume a Breach
+ |
+ Every Service is Vulnerable
+ |
+
+
+ | 3
+ |
+ Assume a Breach
+ |
+ Every Service will be Exploited
+ |
+
+
+ | 4
+ |
+ Assume a Breach
+ |
+ The Cluster Network is Hostile
+ |
+
+
+ | 5
+ |
+ Assume a Breach
+ |
+ Clients will Send Malicious Requests
+ |
+
+
+ | 6
+ |
+ Always Verify - Eliminate Implicit Trust
+ |
+ Authenticate the Service
+ |
+
+
+ | 7
+ |
+ Always Verify - Eliminate Implicit Trust
+ |
+ Authenticate Service Request Senders
+ |
+
+
+ | 8
+ |
+ Always Verify - Monitor Behavior
+ |
+ Verify the Service Instance Behavior
+ |
+
+
+ | 9
+ |
+ Always Verify - Monitor Behavior
+ |
+ Verify Service Request Behavior
+ |
+
+
+ | 10
+ |
+ Always Verify - Monitor Behavior
+ |
+ Verify the Client Behavior
+ |
+
+
+ | 11
+ |
+ Always Verify - Minimize Explicit Trust
+ |
+ Enforce Least Privilege Universally
+ |
+
+
+
+### 1. Every Image Includes Vulnerabilities
+
+Organizations must recognize that all cloud native images inherently contain vulnerabilities. It is imperative to understand that no image is free from potential security flaws. Dependencies, base images, development tools, repositories, and continuous integration/continuous deployment (CI/CD) tools are all susceptible to exploitation, leading to vulnerable images. The extensive amount of code and complexity in how that code is introduced in the build systems or final image built presents numerous opportunities for threat actors to compromise target application and environments throughout their lifecycle.
+
+### 2. Every Service is Vulnerable
+
+Organizations must acknowledge that all deployed services are inherently vulnerable. This assumption should guide the planning and implementation of security measures. Any service deployed within a cloud native environment should be presumed to operate based on a vulnerable image and/or vulnerable configuration and that it will expose those vulnerabilities through its service API.
+
+It is common for organizations to become aware of vulnerabilities when Common Vulnerabilities and Exposures (CVEs) related to their services are published. However, this awareness often comes after a period during which the services were susceptible to attack.
+The absence of a known vulnerability does not mean a system is secure; vulnerabilities may exist that have yet to be discovered or disclosed. CVEs are typically published following the detection and reporting by white hat security researchers, but malicious actors may exploit these vulnerabilities long before they are publicly known.
+
+### 3. Every Service Will be Exploited
+
+Organizations must adopt the perspective that any cloud native deployed service is susceptible to exploitation at some point. When deploying a service, it is essential to assume that it may be exploited through various vectors, including internal malware infiltration, insider misuse, or unauthorized access to credentials or control systems.
+
+This assumption necessitates a comprehensive and proactive approach to security, wherein continuous monitoring and rapid response mechanisms are integral components. By acknowledging the inevitability of exploitation attempts, organizations can better prepare to detect and mitigate threats promptly, minimizing potential damage.
+
+### 4. The Cluster Network is Hostile
+
+Organizations should treat the internal cluster network as inherently hostile and untrusted. This assumption is critical for developing a robust security posture. It is essential to recognize that the cluster network can be compromised, and malicious entities may have the capability to inject and extract traffic within it.
+
+Treating the cluster network with the same level of suspicion as external networks necessitates the implementation of stringent security measures. These measures include robust network segmentation, continuous monitoring, and the application of advanced security protocols to detect and mitigate potential threats.
+
+### 5. Clients Will Send Malicious Requests
+
+Organizations should operate under the assumption that clients may send malicious requests — even those presenting valid credentials and exhibiting consistent behavior over time.
+
+Credentials can be stolen, and users may intentionally or unintentionally abuse their access rights. Legitimate user accounts, or seemingly benign machines, can be appropriated by malicious actors to send hostile service requests. Therefore, it is imperative to monitor and scrutinize each request thoroughly to identify and mitigate potential exploitation attempts.
+
+### 6. Authenticate the Service
+
+Organizations must ensure that clients verify the identity of any service before initiating a service request. This authentication process is crucial for both internal and external clients interacting with services within the cloud native environment.
+
+This action necessitates the implementation of robust identity verification mechanisms to confirm that the service being approached is legitimate and not a fraudulent entity. Such measures are essential to prevent impersonation attacks and to maintain the integrity of service interactions.
+
+### 7. Authenticate Service Request Senders
+
+Organizations must ensure the identity verification of all service request senders before processing their requests. This verification process applies to both internal and external senders, including users and machines interacting with cloud native services.
+
+Implementing robust identity verification mechanisms is essential to confirm the legitimacy of each request sender. This includes verifying credentials and continuously monitoring the behavior of request senders to detect any anomalies that might indicate a compromised identity or malicious intent.
+
+### 8. Verify the Service Instance Behavior
+
+Organizations must continuously monitor and verify the behavior of service instances to ensure they are not being exploited. This necessitates the implementation of dynamic, per-instance evaluation processes that assess whether service instances are operating as expected.
+
+Organizations should promptly identify and mitigate misused service instances — restoring expected behavior and removing malicious actors — while maintaining overall service stability. The faster a compromised service instance is terminated, the lower the gain obtained by the attacker, resulting in a reduced overall value to attackers.
+
+### 9. Verify Service Request Behavior
+
+Organizations must operate under the assumption that even clients providing credible credentials may exhibit malicious behavior, such as when an offender has stolen client credentials. Furthermore, organizations should consider that a client with a history of good behavior might attempt to compromise the system in future requests. An attacker might leverage a legitimate user’s credentials or embed malicious code within a legitimate machine to send service requests.
+
+Therefore, it is crucial to always assume that any request made to a service API could potentially contain an exploit. Requests should be regarded as potential vectors for exploiting vulnerabilities within the service API. Relying on the implied trustworthiness of requests from authenticated senders is insufficient. Instead, a dynamic, per-request evaluation process must be employed.
+Each request should be meticulously assessed and assigned an appropriate Confidence Level, based on its potential to be an exploit. This continuous scrutiny ensures that organizations can effectively mitigate risks associated with seemingly legitimate but potentially harmful requests.
+
+This principle is discussed in NIST 800-207 Section 3.3: “Trust Algorithms.”
+
+### 10. Verify the Client Behavior
+
+Organizations must not assume that a duly authenticated service client is not a potential attacker. Trustworthiness should not be inferred based on authentication alone, as credentials can be stolen, insiders may become malicious, and attackers might be present within the sender’s system. Consequently, a dynamic, per-client evaluation process is necessary.
+
+This evaluation should consider the client's past behavior, including both its normal activities and the historical activities. Additionally, any external information about the client’s identity should be considered. For instance, if the identity is another service, this information may encompass the service's behavior, as outlined in the principle of monitoring service behavior.
+
+### 11. Enforce Least Privilege Universally
+
+Despite being discussed for twice as long as the concept of Zero Trust, the enforcement of least privilege remains an area of significant vulnerability in many systems. Organizations must implement dynamic and fine-grained access control to ensure that verified identities are only permitted to perform operations that align with their role and trustworthiness.
+
+Access to services should be evaluated and granted on a per-request basis, taking into account various parameters to make informed access decisions. These parameters include assessing whether the requested operation is appropriate for the identity in question, evaluating the Confidence Level of the sender's true identity, determining the likelihood that the request is not an exploit, and considering the overall context of the request.
+This context might include factors such as whether the sender is expected to make requests at that particular time of day, from a specific IP range, or in a certain sequence.
+
+# 2. Modeling a Cloud Native Zero Trust Architecture
+
+Having established the foundational philosophy of Zero Trust, we now turn our attention to the concepts and approaches necessary for building Cloud Native systems that adhere to these principles. First we will outline a three-step Zero Trust process where entities are identified, verified, and controlled. We will then define what we consider as key elements for constructing a Zero Trust Architecture (ZTA) within a cloud native environment, in-line with the principles as described above.
+
+We remind readers that the architectural elements outlined here are the result of one way to adhere to the principles as a whole— and there are cases where not all architectural elements may be required.
+
+## Foundational Terms
+
+Before we go deeper, we must first establish some key terms: Confidence Levels, Active Observers, and Security Behavior Analytics.
+
+As discussed in [NIST SP 800-207 Chapter 2: “Zero Trust Basics”](https://csrc.nist.gov/pubs/sp/800/207/final), a **Confidence Level** refers to the dynamically calculated level of trust, based on the assessment of a subject and its context. At the end of this chapter, we will discuss an opportunity to enhance the use of Confidence Levels across the cybersecurity ecosystem.
+
+**Security Behavior Analytics (SBA)** refers to the field of Machine Learning and associated data analytics technologies that analyze entity behavior to inform security and confidence decisions. SBA compares an entity's security-related behavior to its norm or other predefined known criteria. The entity’s standard behavior is first examined through security glasses, and the behavior exposed is recorded.
+Once standard behavior is recorded, *Confidence Levels* can be deducted by evaluating the changes in the security-related behavior of the entity. SBA is a superset of traditional data analytics such as User-Entity Behavior Analytics (UEBA).
+
+According to [NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final), the policy decision/enforcement point “passes proper judgment to allow the subject to access the resource.” In this paper we name this essential functionality “Active Observer” while discussing its use and implementation. An **Active Observer** is a process that continuously monitors factors which influence an entity's Confidence Level within the system by collecting comprehensive Security Behavior Analytics.
+
+## The Zero Trust Process
+
+In ZTA, authentication and authorization are managed on a per-request basis rather than per session. Every action is either authorized or restricted, and every behavior is monitored. This rigorous approach ensures that even if credentials are compromised, malicious actions can be blocked.
+
+The Zero Trust process can be distilled into three fundamental steps.
+
+
+
+*Image 1. Three steps of the Zero Trust process*
+
+### Step 1: Identify
+
+Regardless of the client’s location, whenever a client tries to access a resource, their identity must be validated. Clients should never be trusted based on other attributes, such as their location within the network. It is also essential to maintain an auditable record of all clients based on their individual identities, and to periodically revalidate their credentials (*see [NIST SP 800-63](https://pages.nist.gov/800-63-3/)*).
+
+### Step 2: Analyze
+
+Successful client identification should not lead us to fully trust a client’s requests. All internal or external traffic should be evaluated to ensure it is not malicious. Bad actors may gain access to secure areas or valid credentials, and legitimate clients may be compromised to act maliciously.
+
+Continuous analysis of clients, client requests, and services should compare actual behavior to an expected criteria. Organizations must regularly analyze all network and system activity to evaluate the actions and reassess the Confidence Level for each entity.
+
+### Step 3: Control
+
+Restricting access to resources based on client identity, client behavior, request behavior, device posture, and other contextual factors is essential for maintaining security. Specific controls and checks should be applied in front of every service, governing each action of every client.
+This includes avoiding long sessions based on previous credential validations to limit the impact of potential compromises.
+
+The principle of least privilege must be strictly enforced, ensuring that clients have access only to the minimal resources necessary for their tasks. Unnecessary access should be eliminated, even if the associated risk is perceived as low.
+
+Zero Trust advocates for network segmentation into smaller, isolated segments or microsegments. Each service should be treated as a microsegment, with dedicated access controls to contain breaches and limit lateral movement within the network. By dividing the network into small segments, each containing a single microservice, more granular access controls can be applied, thereby reducing the attack surface.
+This approach prevents lateral movement between microservices, as each microservice operates with its own access control and is safeguarded from neighboring services.
+
+## Cloud Native Zero Trust Architectural Elements
+
+To build a robust ZTA for cloud native environments, we draw inspiration from established frameworks, such as the [US Department of Defense Reference Architecture](https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v2.0(U)_Sep22.pdf), which identifies seven core pillars essential for securing modern systems.
+
+In alignment with these pillars, we identify seven key elements of a Cloud Native ZTA.
+
+**Service Instances** are the individual services offered using containers on cloud native clusters. Securing these includes implementing DevSecOps practices to secure applications from inception through production. Adopting secure-by-design practices, robust image build methodologies, comprehensive image scanning, and secure storage are critical. Service runtime protection methods, such as behavioral monitoring, help establish Confidence Levels for services.
+
+**Client Identities** refer to the unique identifiers of clients sending service requests, whether external or internal. Ensuring the security of these identities involves verifying and monitoring their behavior to form Confidence Levels. Continuous monitoring helps detect and mitigate potential threats from compromised or malicious clients.
+
+**Service Requests** are the interactions initiated by clients to access services. Securing these requests involves monitoring the risks they pose and forming Confidence Levels to assess their trustworthiness. Each request must be scrutinized to prevent exploits and ensure safe interactions.
+
+**Data** encompasses all the information that services handle and store. Effective data security requires categorizing data to apply appropriate security measures based on data types. This ensures that sensitive information is adequately protected. Data classification helps in enforcing policies tailored to the sensitivity and importance of the data.
+
+The **Network** comprises the communication channels between clients and services. Securing the network involves protecting service requests and responses through encryption and other measures to prevent unauthorized access and data breaches. Network security encompasses measures to protect data in transit and to monitor for any suspicious activities.
+
+**Access Control** refers to the policies and mechanisms that govern who can access what resources. Implementing comprehensive access control policies is essential for securing services. This includes enforcing micro-segmentation within clusters and applying granular access controls using gates in front of services. Access control decisions should consider the Confidence Levels of identities and requests, as well as the data types of both requests and responses.
+
+**Automation** involves using tools and processes to manage the deployment, configuration, and auditing of cloud native components. Ensuring that zero trust principles are followed throughout these automated processes is essential. Automated removal of suspected service instances based on their Confidence Levels further enhances security.
+
+
+
+*Image 2. Note that the service request sender (aka client) may be malicious. \
+The Network and Data may also be compromised.*
+
+In cloud native environments, client identities may be malicious, service requests may include exploits, service instances may be compromised, data may contain vulnerabilities, and the network may be hostile. Given these potential threats, it is imperative to deploy an "Active Observer" to continuously assess the Confidence Levels of these entities.
+
+Cloud Native Zero Trust extends access control to include the assessment of Confidence Levels for client identities and service requests. Additionally, Zero Trust extends automation processes to consider the Confidence Levels of service instances. This comprehensive approach ensures that security measures are dynamically adjusted based on real-time assessments, maintaining the integrity and security of the cloud native environment.
+
+## New Proposal for Confidence Levels
+
+Confidence Levels have been an integral component of the discussion in this chapter, and their proper implementation is crucial to the success of modern ZTAs. However, as previously mentioned, there is a notable deficiency in the technical ecosystem regarding the generation and utilization of Confidence Levels as a data type.
+
+While many types of services can function as an Active Observer or Security Behavior Analytics platform, the ability to rapidly interpret and respond to Confidence Levels depends on a system designer's ability to effectively integrate disparate tools.
+
+This presents a significant opportunity: if the community were to rally around a centralized standard for communicating Confidence Levels, it would enable tools to speak a shared language, facilitating easier integration and more precise responses across the board.
+
+Adopting a centralized standard for Confidence Levels would not only enhance integration and precision across security tools but also pave the way for developing advanced tooling solutions that can fully leverage these improvements.
+
+However, this level of maturity is not required to make early strides incorporating Confidence Levels, and is simply proposed here as the logical next step for gaining the highest value from the technologies in a ZTA.
+
+# 3. Cloud Native Zero Trust Architecture Design
+
+With the key elements of Cloud Native Zero Trust Architecture (ZTA) now established, we turn to the process of translating these concepts into a cohesive, practical design. The strength of any Zero Trust system lies in its ability to continuously verify and control every entity interacting within the environment. This chapter focuses on how to build such a Cloud Native system and cope with the different potential breaches as shown in Image 3.
+
+
+
+*Image 3. All potential breaches in a Cloud Native system should be addressed as part of a \
+Zero Trust Architecture design*
+
+To deal with a breached cloud network, we introduce Peer Identities and Secure Communication. Then, to handle breached clients, we introduce Behavior Verification enhanced Access Control. Last, to mitigate the impact of breached cloud service instances, we introduce Behavior Verification enhanced Instance Confidence Automation. Together, this creates a robust system that aims to cope with the different potential breaches.
+
+At the heart of Cloud Native ZTA is the concept of identity—every ZTA entity must have a unique, verifiable identity. Traffic from unknown entities, lacking an identity which cannot be traced to its source, leaves us unable to track and control the entity in question. In this chapter, we will explain how to establish these identities, secure their communications, and ensure that the behavior of all entities is constantly scrutinized and verified.
+
+## Peer Identities
+
+In a Cloud Native Zero Trust Architecture (ZTA), every entity—whether acting as a client, a service, or peer in a peer to peer network—must be uniquely identifiable. This identity forms the foundation of all security mechanisms, enabling the system to trace actions, control access, and verify trustworthiness in real-time.
+
+Cloud Native applications typically consist of multiple **microservices**, each composed of **Pods** that handle specific requests from internal or external clients. These Pods may also serve as clients themselves, sending requests to other microservices or external cloud services. When designing a cloud native ZTA, each microservice must be assigned a unique and verifiable identity, allowing us to track their behavior and enforce security policies.
+
+Assigning a single identity to all Pods within a microservice could limit visibility and control. When pods of a microservice send requests to other services, it is recommended to enable tracing the requests back to a specific Pod. This can allow identifying misbehaving, potentially rogue Pods. Depending on policy, such Pods may be restarted without affecting other pods of the microservice.
+
+**Hierarchical identities** for Pods within microservices therefore may offer us the ability both to associate all behaviors of a microservice to the microservice identity; And, at the same time, the ability to associate all behaviors of a specific Pod in a microservice, to the Pod identity, allowing us to perform an appropriate policy based action.
+
+Note that **containerized environments** such as Kubernetes may group multiple containers within a Pod. Under Kubernetes, all containers in the same Pod are managed as one unit and therefore may share the same identity. The Pod's identity can be used to represent both the service it provides and its interactions as a client to other services.
+
+External client entities— whether human users or external systems— must also be uniquely identified to ensure traceability and control over their actions.
+
+After identities are assigned to all clients and services, the next step is to ensure that communication between these entities is secure.
+
+## Secure Communication
+
+Zero Trust operates under the assumption that offenders may already have control over the cloud network. Therefore, a Zero Trust Architecture (ZTA) must ensure data confidentiality for communication between microservices, or between microservices and external entities. As discussed below, to achieve data confidentiality, we must verify the identity of every service and encrypt all communications.
+However, a ZTA requires not only data confidentiality, but also fine grained access control as well as behavior monitoring. To achieve either, we are also required to verify the identity of every client.
+
+### Data Confidentiality
+
+Every Cloud Native request, whether initiated by an internal microservice or an external client, must be performed using Transport Layer Security (TLS) to encrypt the channel. This guarantees that even if an offender intercepts the data between the client and server from the internal network, it will not gain access to the request and response data.
+However, to encrypt the data, the client and server must first agree on encryption keys. An offender may redirect the client traffic to a fake server and gain access to the pre-agreed upon encryption keys.
+
+Such an attack can be part of a full fledged man-in-the-middle attack or may be used to obtain the Request data without involving the true server. To protect against offenders introducing fake servers, the client must first verify the identity of the service before sending the Request.
+Therefore, the microservice or external service must present a **certificate** signed by an entity that the client trusts apriori. Clients should only send requests to a service after verifying the authenticity of the certificate and verifying that the certificate was indeed provided to the identity of the service being approached.
+
+Combining service certificate verification with encryption suffice for achieving data confidentiality, protecting against data leakage in a cloud native environment under the control of potential offenders. However, a Zero Trust Architecture requires more than data confidentiality.
+It requires fine grained access controls, allowing each client to access only the subset of services as may be needed. It also requires monitoring the behavior of each client. We are therefore required to also verify the identity of every internal or external client.
+
+### Client Credentials
+
+Clients, whether embedded in a microservice or any external systems, must present credentials that are verified by the receiving service. This can be done through tokens—such as JWT (JSON Web Tokens)—or by presenting client certificates that are verified by service instances using mutual Transport Layer Security (mTLS).
+Note that verifying the identity of clients or servers only ensures that the peer has the necessary client credentials and