IMCAFS

 Home

zero trust native security: beyond cloud native security

Posted by tzul at 2020-03-07
all

The premise of a good security system is to establish trust relationship for legal subjects, reduce the security cost through trust under the premise of ensuring business, detect and eliminate malicious behaviors of illegal subjects in time during operation, so trust is the premise of network security. In 2012, the author published an article on trust mechanism in computer journal [9], and later contacted the software definition boundary SDP proposed by CSA of Cloud Security Alliance (now considered as a typical school of zero trust network access). At the dinner party of CSA Cloud Security Summit Forum in November 2014, I met with Jim, CEO of CSA Reavis has some discussions, so self admission has some research on trust mechanism.

Figure 1 group photo of the author and Jim after discussing SDP in 2014

Judging from the development of the industry this year, whether Gartner believes that trust and flexibility are two principles of adaptive security, or the concept of "zero trust" has become a buzzword in the industry, it shows that everyone has reflected that simple stacking security mechanism has been unable to resist increasingly complex application scenarios and attack groups, so return to the origin of security, and think about how to build a trust system A unique phenomenon at present.

This paper attempts to start with the definition of trust, explore the connotation of (zero) trust, and then analyze the relationship between cloud native security and zero trust security. Success on the cloud will integrate zero trust native security with more security protection means and apply various complex application scenarios.

Wikipedia defines trust as [1]: one party (the trusting party) depends on the willingness of the other party (the trusted party) to act in the future. Suppose that given three parties a, B and C, they all interact, as shown in the figure below.

Figure 2 Trust Model

Then trust refers to the willingness of subject a to rely on action (b) of subject B in the future, which has two meanings:

Trust is the judgment of whether subject B will do action (b), including the double judgment of subject B and its action (b). The judgment of subject a on subject B is reputation, which is recorded as reputation (a, b).

Trust is used to judge the possibility of subject B's future behavior (B's previous behavior has become a's experience). It shows that trust itself is subjective and uncertain. Fuzzy mathematics and evidence theory are all mathematical models to support trust measurement.

Then the trust (B, a) of subject a to B is formally expressed as:

Trust (B, a) = t ({action (b)}, reputation (B, c)), where t is the trust evaluation function

It can be seen that the trust of action (b) behavior of subject a to B is a comprehensive evaluation of its reputation evaluation (B, c) by combining the observation of historical behavior of a to B {actions (b)} and the third party (such as subject C). In fact, the measurement of trust will be more complex, which needs to consider the reliability of observation behavior (i.e. evidence), as well as the decline of trust over time and other factors.

When the trust mechanism is applied, there will be various forms according to different scenarios and requirements, such as Iam, access control, border control, etc., and the specific products will be more diverse. But at the core, trust management has four elements:

Principal identity attribute confirmation, i.e. identification

Attribute confirmation of resource, that is, attribute enumeration

Authorization refers to the authorization of the principal to the resource operation

Operation control, i.e. enforcement

Figure 3 trust mechanism representation

The mainstream trust management mechanism in the industry adopts the deterministic trust evaluation method, which remains unchanged for a long time after setting. Although it simplifies the policy formulation and system operation time mechanism, it does not take into account the context change, which is one of the fundamental reasons for the frequent occurrence of network security events.

From the perspective of subject identity, the subject identity may be counterfeited, or the legitimate subject may do evil under certain conditions. More specifically, you can refer to the operation of password verification login system. Although the system security policy requires users to set complex passwords and update them regularly, it cannot completely assume that users are trusted. Attackers can use common attack methods such as phishing and database dragging to obtain user passwords. In addition, although the updated passwords are complex, in order to facilitate memory, the passwords used each time are regular and easy to be cracked. Therefore, more and more Iam schemes are using passwordless, MFA, biotech, etc.

From the perspective of asset attribute, the five tuple destination address in firewall policy indicates the accessed resource. However, with the change of business and other environment, the attribute of resource will also change. If the security policy is not updated in time, the previous network address will be used as the five tuple destination address, which will obviously lead to the failure of access control. In fact, this phenomenon is very common in many large institutions that lack effective and safe operation.

Now in some risk-based models, such as Gartner's adaptive access control, security policies need to be dynamically adjusted according to the context of the principal behavior, which also reflects that trust is subjective, dynamic and uncertain.

From the perspective of policy control points, for example, access control in the cloud, with the migration of virtual machines, the subject, resource attributes and security policies have not changed, but the host where the resource is located has changed. If policy control is still performed on the virtual network of the host, obviously, the access behavior of the subject cannot be controlled. For example, the traffic in the virtual subnet in the cloud will not pass through the virtual router or the virtual firewall. If these virtual devices are used as the policy control point of the access behavior in the subnet, it is also inappropriate. It can be seen that the access control point should be dynamically deployed according to the access path between the subject and the resource, and the disposal of its data plane should be consistent with the security policy of the control plane.

Therefore, a good trust management mechanism, in the control plane, needs to ensure that the subject, resource attributes and security policies are aligned during the operation process. In the data plane, the operation control point can always be on the access path of the subject and resource.

We have analyzed the trust management, so what is the zero trust of "rampant"?

We can't help but ask, is there zero trust in the world?

The answer is "no" and "yes".

First of all, from the perspective of human nature, there is "no" zero trust in the world. Trust has been the premise of all important human activities since ancient times. There is a saying in the Analects: people can't stand without trust, industry can't thrive without trust, and country can't fall without trust. We often see that when an organization's security manager believes that there is a risk in the business, he or she often limits the access rights of legitimate users or downgrades the business functions to meet the requirements of risk compliance. However, this approach does not distinguish between legitimate users and malicious attackers. It generally believes that users are untrustworthy, constrains the normal development of business from the result, and reduces the revenue of various businesses of the enterprise.

Secondly, from the perspective of technology, there is no trust in the world. So far, at least, I have seen that blockchain and its applications can be zero trust. Because the blockchain has a decentralized consensus mechanism, which enables the upper level smart contracts to be executed uniformly and globally, thus supporting the multi-party transactions without trust or weak trust in advance. It can be said that consensus algorithm is the basis of zero trust in public chain, but such zero trust is basically based on the relationship between machines, which is obviously not the "zero trust" in the current industry. The trust mechanism of people-oriented business should also be based on the traditional trust model.

Therefore, from the above analysis, it can be seen that "zero trust" is misleading in the literal sense. There is no business in the world that does not trust any subject at all. The so-called "zero trust" security, more precisely, should be "default mistrust, always verify everywhere" security.

From the technical point of view, to achieve trust management, or work on identity, or work on control, so the existing industry's zero trust scheme must fall into a specific technical field, such as identity management, access control, regional isolation, application security, etc.

As the first link of trust, identity and rights management (IAM, idaas and PAM) has naturally attracted the attention of the industry. For example, duo security [12] acquired by Cisco is the starting of Iam, which is integrated into Cisco's zero Trust Scheme [13]. In addition, if centrify divides its idaas business into independent company idaptive at the end of 2018, it is also applying the concept of zero trust, and there are similar schemes in China's Kyushu Yunteng.

When the subject performs actions, the most common way to judge the authority and behavior of the subject is network access control. This kind of zero trust scheme is called zero trust network access (ztna). There are two schools divided into CSA SDP and beyondcorps. However, in Gartner's latest report, these two categories are collectively referred to as software definition boundary SDP, so the former is called CSA SDP, which means that it is the first narrow sense SDP school proposed by CSA.

The CSA SDP is shown in the figure below. The authentication request is initiated by the client. The controller issues the instruction according to the access control policy judgment, and the gateway finally releases or blocks the instruction according to the instruction.

Figure 4 CSA SDP

Beyondcorp's route is the first one to see the Google beyondcorp project. Its process is as follows: authentication request is initiated by the service accessed by the user, and the control point is also on the service side, so the role of the service is agent.

Figure 5 agent based ztna route

From the perspective of effect, these two technical routes hide the later applications. Unless users provide their own identity and access resources, they cannot access the applications. From the deployment point of view, CSA SDP needs client installation agent, so the environment requirements are high. At present, it is mainly used in the scenario of replacing VPN. There are many such companies, such as cyxtera, metanetwork, Verizon, etc.

As a result, "zero trust" has a lot to do with isolation. With the help of micro isolation technology, some cloud vendors can naturally isolate services according to different granularity, and also provide zero trust. For example, VMware proposes to use micro isolation to reduce attack surface in NSX products, although this technology has existed for a long time before the concept of zero trust caught fire. So, this leads us to an interesting direction: the relationship between zero trust and cloud computing security.

It is worth noting that although the development trend of cloud computing at home and abroad is different, the common trend is that the market share of public cloud is increasing and enterprises are going to cloud. In this trend, the key businesses of enterprises will be more and more deployed on the public cloud, so their exposure and attack will inevitably become larger. For example, zero trust technologies such as SDP can deploy some internal businesses to the public cloud, but these businesses are not exposed to the outside world. Attackers cannot find these businesses from the Internet, but legitimate users can use clients or agents Access these internal businesses after validation.

In addition, with the rapid development of sdwan, the branches of the enterprise are interconnected through ucpe, and the boundary equipment is greatly weakened. On the contrary, sdwan security manufacturers such as zscalar provide various cloud security capabilities in the operator network. The employees of the enterprise can register the services of the branches of the enterprise at any place and any terminal, so in such a complex network environment, can the service be provided To minimize the appearance of public affairs and achieve a globally consistent access strategy? This year, sdwan security vendors also joined in zero trust security.

In addition, as mentioned earlier, virtual resource migration and business changes in the cloud can be frequent to the second level, so whether the security policy can follow the business and whether the separation granularity between businesses can be minimized is also the original demand of zero trust.

From these perspectives, it can be said that cloud computing security is the earliest industry driving force for zero trust.

The biggest characteristic of cloud computing system is the virtualization and software of all resources, and the centralization of platform. Among them, for example, authentication and access control mechanisms are provided by the cloud computing system natively. For example, openstack provides keystone authentication service, security group, firewall as a service. Kubernetes supports a variety of authentication, authorization mechanisms and network policies, so these cloud platform control planes and data planes are natively supported with zero trust.

Specifically, in the management control plane of openstack, all users or components' operations on resources need to go through the authentication of keystone, obtain the certificate token after authentication, and attach the token to each operation, then judge whether the subject has the authority to perform the operation.

export OS_USERNAME=adminexport OS_TENANT_NAME=adminexport OS_AUTH_URL=http://controller:35357/v2.0

#keystone token-get+-----------+----------------------------------+

| Property  |             Value                |

+-----------+----------------------------------+

| expires   |      2013-05-07T13:00:24         |

|    id     | 5f6e089b24d94b198c877c58229f2067 |

| tenant_id | f7e8628768f2437587651ab959fbe239 |

| user_id   | 8109f0e3deaf46d5990674443dcf7db7 |

+-----------+----------------------------------+

Then 5f6e089b24d94b198c877c58229f2067 can be placed in the x-auth-token field, and other related resources can be accessed by sending a request through curl. Since all operations need to be authenticated first and then authorized according to token, the trust of management plane is complete.

In kubernetes management control plane, kubernetes natively supports authorization mechanisms such as RBAC authorization [2], ABAC authorization [3], and node authorization [4]. The administrator or service authenticates through the certificate, and then the system judges whether the principal can operate on the resource according to the role or attribute.

As shown in the following command, you can create a role pod reader that can execute "get, watch, list" on the pod

kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

The access of cloud computing system data plane will involve the isolation and access control of computing resources. There is no doubt that resource isolation is a natural feature of virtualization, so VMware calls its differential segment zero trust; as for access control, it is divided into two parts: service exposure and internal network access.

In the VPC environment, if there is no floating IP assigned to the virtual machine, the external cannot access the virtual machine in the VPC. For example, Kubernetes only creates a new Pod or Deployment, and the external cannot access the business on the Pod. Therefore, the cloud computing resource exposure is not available by default, thus avoiding most threats from the Internet. When openstack allocates floating IP for virtual machine, kubernetes allocates ingress or nodeport service for pod, these cloud resources provide services to the outside world, and users can access them outside, and there are exposed risks. So in this scenario, beyondcorp's SDP model can help enterprises hide sensitive services and provide fine-grained access control. Although this is not the original security capability provided by the cloud platform, SDP can easily connect to the major public clouds with the open interface of the cloud platform. In contrast, if similar SDP services are deployed in the intranet of traditional enterprises, the traditional network structure and server application need to be greatly reformed, which is almost impossible to implement (so now traditional enterprises mainly use SDP instead of traditional VPN to achieve fine-grained access control).

In the internal network, the attacker can also be prevented from moving horizontally by the zero trust access control mechanism.

For example, in openstack system, the virtual machines inside the same host are isolated by VLAN, the virtual machines of different tenants are isolated, and the internal network access can realize the white list mechanism through the security group, so in this scenario, zero trust protection can indeed be realized.

In kubernetes, access control and isolation between internal containers can be implemented by network policy. It should be noted that business network usually depends on CNI plug-ins, so network control also depends on CNI implementation. If the network policy is not turned on, by default, pods are interconnected [5], so to achieve zero trust in the network, you need to set the network policy to the white list mode. For example, the following policy is to disable all incoming and outgoing traffic by default:

apiVersion:networking.k8s.io/v1

kind:NetworkPolicy

Metadata:

    name:default-deny

Spec:

    podSelector:{}

    policyTypes:

    -Ingress

    -Egress

It can be seen that the programmable and software capabilities of the data plane of cloud computing system can indeed provide zero trust authentication authorization, resource isolation and access control mechanisms.

The last section mainly talks about the zero trust of IAAs and PAAS platforms. In the SaaS scenario, driven by agile development and efficient operation, users are increasingly using cloud native architectures such as service mesh to develop applications. Although the infrastructure where these applications are located is still under active development, the concept of zero trust has been put into practice due to the modern and software enabled infrastructure and the protection requirements from Internet attacks.

In the cloud native scenario, the granularity of the application will be very fine. A container usually only runs one or a few processes, so the service is called microservice. Therefore, generally, the implementation of a business requires the interaction of multiple microservices. Therefore, in the cloud native scenario, the access relationship between services is very complex. Instead of relying on the implementation of fixed access control logic, we should determine the security policies between microservices according to the business logic, divide the boundaries of microservices for continuous and effective isolation, and have consistent access rights between microservices Limited control becomes very important. In order to solve this problem, cloud native systems usually have authentication mechanisms of data and management plane.

In the service grid scenario, zero trust should also cover the interaction between microservices, which requires the use of cloud native oriented service zero trust mechanism. A typical solution is istio of Google. We have analyzed it in the previous article (security mechanism protection of istio). Please refer to the official document [6]. From a functional point of view, istio can seamlessly add the functions of authentication authorization and encrypted communication to microservices. The idea is to use the RBAC authorization mechanism of kubernetes through the policy controller to control the access from the resource granularity to a single service, so that all service interactions are trusted.

Istio is authenticated by Citadel component and authorized by pilot component on the control plane; on the data plane, sidecar container is inserted next to the source and destination services to intercept the incoming and outgoing traffic, and at the same time of encryption and decryption, access control is carried out according to pilot's policy.

Figure 6 access control and data plane of istio

Figure 7 workflow and components of istio

From the effect point of view, if the attacker does not have a legal identity, he cannot move horizontally in the data plane. Because in the network layer, after the network policy white list is set, the illegal access in the network layer is prohibited; in the service layer, the microservice pod open services are less, and authentication and business layer access control are introduced, so it is difficult for attackers to initiate unauthorized connections.

From the data plane analysis, istio and SDP both need to make great changes to the network. For example, IH and ah need to be added to SDP, components need to be added to the client, agents need to be deployed to the server, and the sidecar container of istio needs to be deployed beside all business containers, and traffic is intercepted. The processed traffic is sent back to the business container by rewriting the iptables NAT table.

From the results, SDP deployment in the traditional enterprise network has encountered great challenges due to the above reasons, but it can be predicted that sidecar deployment mode will become the mainstream security protection technology route in the service grid environment. The reason is that sidecar is an invasive deployment mode, but it is fully automated and user-friendly: istio actively monitors k8s API services to obtain new service deployment events, automatically deploys sidecar containers through the warehouse, hijacks traffic through init containers, and finally uses Citadel and RBAC policies for authentication and authorization. On the one hand, the business side has no awareness of the security mechanism, and all development, testing and operation and maintenance remain unchanged; on the other hand, the application can achieve complete authentication and authorization, and ultimately achieve endogenous security.

In practice, cloud native security and zero trust security have some relevance:

Cloud native's trust mechanisms are all zero trust. The open environment of cloud computing and the open interface of cloud services inevitably require cloud native's security to do a good job in trust management. The white list mechanism with global and business consistency is zero trust. Moreover, it is relatively easy to practice the zero trust mechanism in the cloud native environment under the software defined infrastructure. Whether it is the SSO mode of openstack keystone or the invasive sidecar mode, it can achieve compatible business, expand functions and implement the concept of zero trust.

The successful zero trust mechanism is bound to surpass cloud native. Although cloud native applications are becoming more and more popular, it is still a new field after all. In most traditional environments, the zero trust mechanism in cloud native cannot be used directly. This is also the reason that the current domestic zero trust mechanism is only piloted in a few large institutions. However, we need to see that with the more and more reality of foreign infrastructure cloud and enterprise network sdwan scenarios, the traditional trust model of isolation and access control with fixed network segment and identity has been broken, and the demand for business access without distinction of region, terminal and time is more and more strong, so zero trust is so highly praised.

Seeing this, we can draw a conclusion: the cloud's native (zero) trust mechanism will inevitably expand and connect to more environments, such as the enterprise intranet, mobile network, even the Internet of things, industrial Internet, etc., just like the trend that the public cloud begins to connect the enterprise intranet, industrial Internet to the production environment and cloud platform.

Then, cloud native zero trust mechanism needs to start to adapt to more application scenarios other than cloud native with its advanced software capabilities and architecture, and finally realize the zero trust mechanism for fusion environment.

In addition, although zero trust gives us a new concept of trust management, it does not mean that the mechanism of "zero trust" is foolproof and impeccable. In the most extreme scenario, if the access subject has malicious intention, although the identity and permission are normal, its behavior is abnormal, so the answer of "is zero trust silver bullet" is obviously No.

The biggest value of zero trust is to reduce the exposure and attack, so it should be in the prevention stage of Gartner's adaptive security system, or it should be assumed that there is the possibility of attackers' invasion. Just as NIST's zero trust model (NIST. Sp800-207-draft) [7] includes continuous diagnosis and mitigation systems for real-time monitoring and timely response.

Therefore, how to integrate zero trust into the whole security system, we need to design a native formal model and security architecture of zero trust. Firstly, we should define the subject, policy and resource according to the trust model in the first chapter, and dynamically distribute the policy to the corresponding security device, platform or enforcer according to the ability of the existing security resource, so as to realize the global on-demand, dynamic and complete policy control. Please refer to firemon's access control management [8] for details. However, it only includes the control of firewall, and does not support other security or network devices. In addition, automatic response processing needs to be done after detection. At this time, the control strategy can be dynamically distributed according to the environment of network, security resources and attacked resources. This can refer to the software defined security system proposed by Green Alliance Technology [10,11].

To sum up, the "zero trust native security" embodies the concept of zero trust in design and integrates a variety of security capabilities; it can be adapted to the security system of various application scenarios in implementation. It emerges from the concept of zero trust, integrates the self-adaptive security system, organically forms the ability of prevention, detection and response, utilizes the cloud's original security architecture and ability, and adapts to a variety of application scenarios through the software defined architecture.

[1] Trust (social science)https://en.wikipedia.org/wiki/Trust_(social_science)

[2] https://kubernetes.io/docs/reference/access-authn-authz/rbac/

[3] https://kubernetes.io/docs/reference/access-authn-authz/abac/

[4] https://kubernetes.io/docs/reference/access-authn-authz/node/

[5] https://kubernetes.io/docs/concepts/services-networking/network-policies/

[6] https://istio.io/docs/concepts/security/

[7] https://csrc.nist.gov/publications/detail/sp/800-207/draft

[8] https://www.firemon.com

[9] Liu Wenmao, Yin Lihua, Fang Binxing, Zhang Hongli, research on trust mechanism in the Internet of things environment, Journal of computer science,

[10] Green Alliance Technology, 2015 Green Alliance Technology software definition security SDS white paper, 2015

[11] Lvmeng technology, 2016 Lvmeng technology software definition security SDS white paper, 2016

[12] https://duo.com/

[13] https://www.cisco.com/c/en/us/products/security/zero-trust.html

Cloud lab focuses on cloud computing security, solution research and virtualization network security issues. Based on the security protection of IAAs environment, the cloud security protection system with software defined security is proposed by using new technologies and concepts such as SDN / nfv. It has undertaken and completed innovation research projects in many countries, provinces, cities and key industrial units, and has successfully incubated and implemented green alliance technology cloud security solutions. At present, many research reports have been published, including software definition security 2016 edition, 2018 Green Alliance Technology container security technology report, etc.

Past review

CCS 2019 paper interpretation: ble device fingerprint recognition based on automatic app analysis

Inventory of data leakage events at home and abroad in 2019 -- personal information protection is urgent

The science of ATT & CK attack Art

[recruitment] recruitment announcement of interns of Lvmeng science and Technology Innovation Center (long term effective)

Lvmeng technology research communication is operated by Lvmeng technology innovation center, which is the leading technology research department of Lvmeng technology. It includes Cloud Security Lab, security big data analysis lab and Internet of things Security Lab. The team members are composed of doctors and masters from Tsinghua University, Peking University, Harbin Institute of technology, Chinese Academy of Sciences, Beijing post and other key universities.

As one of the important training units of "post doctoral workstation sub station of Haidian Park of Zhongguancun Science and Technology Park", Lvmeng science and technology innovation center has carried out post doctoral joint training with Tsinghua University. The scientific research achievements have covered all kinds of national projects, national patents, national standards, high-level academic papers, professional books, etc.

© 2023