Augmenting Zero Trust Architecture to Endpoints

Using Blockchain: A Systematic Review

Lampis Alevizos Vinh Thong Ta Max Hashem Eiza
School of Psychology and Computer School of Psychology and Computer School of Psychology and Computer
Science – Laboratory of Security and Science – Laboratory of Security and Science – Laboratory of Security and
Forensic Research (SAFeR) Forensic Research (SAFeR) Forensic Research (SAFeR)
University of Central Lancashire University of Central Lancashire University of Central Lancashire
(UCLan) (UCLan) (UCLan)
Amsterdam, The Netherlands Preston, UK Preston, UK
[email protected] [email protected] [email protected]

Abstract—With the purpose of defending against lateral challenges, as well as provide ideas and research directions to
movement in today’s borderless networks, Zero Trust tackle these problems.
Architecture (ZTA) adoption is gaining momentum.
Considering a full scale ZTA implementation, it is unlikely that A. The problem with traditional perimeter-based
adversaries will be able to spread through the network starting architectures
from a compromised endpoint. However, the already In the traditional perimeter-based security model, we
authenticated and authorised session of the compromised usually assume that the organisation resources and assets
endpoint can be leveraged to perform limited, though malicious
inside the perimeter are benign and trusted. Perimeters are
activities, ultimately rendering the endpoints the Achilles heel of
ZTA. To effectively detect such attacks, distributed usually protected by security measures such as firewalls or
collaborative intrusion detection systems with attack scenario- intrusion detection systems. This model seems to be less
based approach have been developed. Nonetheless, Advanced effective in the world of cloud computing and remote
Persistent Threats (APTs) have demonstrated their ability to working, as indicated by several cyber-attacks (e.g., [1], [2]
bypass this approach with high success ratio. As a result, [3] [4] [5]) targeted employees working remotely.
adversaries can pass undetected or potentially alter the Trust is the fundamental principle that a traditional
detection logging mechanisms to achieve a stealthy presence. perimeter-based security model relies on. The employee’s or
Recently, blockchain technology has demonstrated solid use collaborators’ devices and organisation assets (i.e., endpoints)
cases in the cyber security domain. Motivated by the can be trusted by default regardless of their condition. Once
convergence of ZTA and blockchain-based intrusion detection the attackers managed to take control over any of these
and prevention, in this paper, we examine how ZTA can be endpoints, they get inside the perimeter and gain access to
augmented onto endpoints. Namely, we perform a systematic
further sensitive information and assets. In addition, in the
review of ZTA models, real-world architectures with the focus
perimeter-based security model, organisation would not be
on endpoints, and blockchain-based intrusion detection systems.
We discuss the potential of blockchain’s immutability fortifying able to protect their assets managed by a third-party cloud
the detection process, and the identified open challenges as well service provider.
as the possible solutions and future directions. Firewalls, antivirus technologies, intrusion detection and
prevention system (IDS/IPS), Web App Firewalls (WAFs), in
Keywords — Zero trust architecture, blockchain, distributed other words, the big stone walls and armoured front doors are
ledger technology, collaborative intrusion detection, borderless not enough to keep modern IT and Operational Technology
networks. (OT) environments safe [1]. Perimeter-based security was the
main concept adopted by multiple companies, especially when
I. INTRODUCTION their data resided in on-premises data centres. The traditional
With the revolution of cloud computing and the cloud- defensive model founded on internal and external disparity is
based services, most resources and data of organisations or becoming obsolete [2], while at the same time the threat
businesses are no longer stored on premises. Moreover, landscape is dramatically evolving [3], ultimately leading into
pandemics like COVID-19 have significantly changed the the fall of perimeter-based security architecture.
work pattern, where most employees and businesses had to B. Zero Trust Architecture (ZTA) as a promising
switch to working from home. Homeworking (and remote
solution
working) open organisations up to new and serious security
risks, as many “untrained” employees connect to the work IT To cope with today’s complex network infrastructures and
systems with their own devices. The examples of cloud the current and advancing threat landscape, a new security
computing and remote working mean that businesses have to architecture is needed. ZTA has emerged by establishing a
expand their digital perimeter and perimeter-based security borderless digital identity-based perimeter, where data are on
and adapt to the new trends. the epicentre of the security architecture, assume breach
mindset is dominating the threat model, whereas also leading
In this paper, we highlight the problems of perimeter- the access control landscape, operations, hosting
based architecture, and discuss the concept of zero trust environments, endpoints and inter-connecting infrastructures.
architecture as a promising approach to tackle these problems. Nonetheless, ZTA remains less investigated and far less
We start by reviewing the core tenets and requirements of zero implemented for the time being. ZTA reassesses and
trust and in continuation, categorise existing zero trust reconsiders the traditional perimeter-based architecture and
implementations. Finally, we discuss the open questions and fosters a new security architecture whereby default, any
device, system, user or application should not be inherently

XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE

trusted regardless of its physical or network location. On the explicitly verified, authenticated, authorised and monitored at
contrary, trust shall be earned and proven at all time and all times. That said, one of the core objectives of zero trust is
locations. Nevertheless, it would be ambiguous and confusing to severely inhibit the ability of adversaries to move laterally,
to state that trust is eliminated, and maybe inaccurate. That once they successfully manage to compromise a user’s
said, within ZTA context, trust is and should be minimised till device, or even simply steal their credentials. As such, the IT
proven otherwise via ZTA tenets and core components (more infrastructure needs to be shaped and prepared accordingly.
on ZTA tenets in sub-section II.C).
The traditional perimeter-based security architecture
A similar discussion, and in fact, an analogy regarding trust creates multiple zones of trust [20]. Not all zones adhere to
levels, comes into play with Distributed Ledger Technology the same rules of trust, or to the same level of trust. In fact,
(DLT) and blockchain often referred to as trust-less [4].
users might not be able to even reach into the next zone, if
Conceivably, a more precise approach to portray trust in
blockchain would be based on distributed trust, thus trusting not explicitly allowed by the relevant component. Therefore,
everyone in aggregate [5]. DLT and blockchain are two the subject model provides a so-called defence-in-depth, as
elements that could possibly enhance ZTA, due to their discussed by Smith [21] and depicted in Figure 1.
inherent attributes of immutability, availability and consensus
[6], through multiple use cases. For instance, latest research
[7] [8] [9] in reference to cyber intrusion detection domain,
has concentrated beyond and above the simple and single
intrusion detection system methodology, towards distributed
collaborative approach, namely distributed collaborative
intrusion detection systems (DCIDSs).
II. ZERO TRUST
In this section, we provide a brief history of “zero trust” and
ZTA, and we discuss the core tenets, core capabilities of zero
trust, as well as different zero trust models.
A. History of Zero Trust Architecture
Jericho Forum in 2004 introduced the, radical for the time
being, idea of de-perimeterization [10], which developed Figure 1 – A traditional security architecture.
further and improved later into the broader concept of zero
trust. Despite the term “zero trust” coined by J. Kindervag As opposed to the traditional security architecture, which
[11] back in 2010, it appears that the actual zero trust concept is also referred to as the castle-and-moat approach [22] due
has been present within cybersecurity domain before that. to their inherent similarities, zero trust demands to start
The United States Department of Defence and Defence thinking, building and protecting from the inside out.
Information Systems Agency (DISA) commenced work
towards a more secure strategy, named “black core”, which Based on the abovementioned works from Google [13]
was published in 2007 [12]. Black core discussed the [14] [15] [16] [17] [18], Jericho [10] and J. Kindervag [11],
transition from a perimeter-based security architecture to one there is one immediate and important observation, namely,
that emphasises on securing individual transactions. virtual private network (VPN) technology can be eliminated
once the network locality dependency becomes irrelevant.
As ZTA continued to evolve, identity-based architectures VPNs in short, allows user A working remotely, to connect
slowly gained attention and even more gradually broader to office B, via a secure encrypted channel. More precisely,
acceptance. However, it should be noted that the acceptance the tunnel from A to B is encrypted, however, A and B as
of these can be attributed to cloud and mobile computing endpoints are irrelevant and should be protected by other
adoption. Google published a series of six documents under means since VPN encryption is only referring to the A to B
the name “BeyondCorp” on how to achieve a zero trust tunnel itself. When user A is authenticated and the tunnel is
architecture [13] [14] [15] [16] [17] [18]. The BeyondCorp successfully established, then he/she receives an IP address
project advocates for the concept of de-perimeterization, on the remote network B. Furthermore, on that tunnel, the
arguing that perimeter-based security controls are no longer traffic from point A to network B is decapsulated and routed,
suffice. Therefore, security controls should be expanded from therefore leading to an “official” backdoor. Therefore, if we
the perimeter to users and devices, respectively. Following start considering the network location as irrelevant, while at
the successful implementation of ZTA, Google abandoned the same time apply a proper set of controls along with a
the traditional way of remote working based on VPNs. They modern architecture, VPN can be eliminated provided there
managed to provide reasonable assurance that all corporate are no further dependencies (e.g., apps with legacy
users could access Google’s network via insecure and protocols). That said, authentication and authorisation along
unmanaged networks, however. with policy enforcements should immediately move as far to
the network edge as possible. A reference ZTA is shown in
B. From traditional perimeter-based to Zero Trust Figure 2 that reflects the arguments above. For the sake of
Architecture simplification, in the figure, we add only the core
The term “zero trust” was built upon the fundamental idea components, for instance, a local broker (LB), remote
that trust in users, devices, workloads and network traffic employee, various mobile devices, untrusted clients, and
shall not be implicitly granted [19]. All entities must be
various services that require different levels of protection assume that a potential adversary can intercept any type of
respectively. communication happening throughout the network. As a
result, all communications should be end-to-end encrypted
externally or internally.
4) The Principle of Least Privilege
All entities must be restricted to the least amount of privilege
required for that specific entity to fulfil its mission. This
includes what can be accessed, where it can be accessed, from
and even for how long it can be accessed. Moreover, the
overall trustworthiness of an entity must be evaluated based
on the context or attributes, ultimately indicating if it shall be
trusted or not.
5) Continuous monitoring and adjusting
Every entity (insider or external) should be monitored.
Monitoring is not referring to malware signatures for
instance, but at a high level including all network traffic,
system events, access attempts regardless of failure or
Figure 2 – A high level ZTA reference. success etc. Such must be continuously crosschecked against
what is being already stated as allowed, therefore, the
In order to make this ZTA reference vendor agnostic, we outcome should be used to adjust the relevant policies when
simply use the generalised term of control plane, and we needed.
distinguish between control plane and data plane. This
concept is already known in cloud architectures, and we use Jointly, these five core tenets form the concept of zero
the same analogy here to leverage the fact that control plane trust. Although the abovementioned papers can be found with
poses inherent and unlimited access on data plane. All access slightly different titles or description, the essence remains the
requests to resources must be directed through the control same. Those principles must be applied at many different
plane, where a set of authorisation and authentication levels, for instance, users as well as administrators, and on
policies, rules and context parameters must be met. Access to many different domains, such as traditional network as well
more private resources, e.g., a payment router or a mainframe as cloud infrastructures. It needs to be highlighted, that
resource can be further restricted based on a mixture of role- although zero trust is gaining momentum and the market for
based access controls (RBAC) enhanced by context-based the zero trust related products is expected to double by 2024
access controls (CBAC) on the same level. Finally, if the [25], there is not enough vendor agnostic, scientific critical
control plane concluded that the request should proceed, it literature available.
coordinates and configures as necessary the data plane to
accept the connection from the requestor explicitly. D. Zero Trust Core Capabilities
Additionally, it can potentially coordinate the setup of an In the following, the core capabilities of a zero trust
encrypted tunnel for the requestor and the destination architecture are discussed based on the NIST Special
resource. Publication 800-207 [2], Google’s BeyondCorp [17] [16]
and Kindervag et al. [19].
C. Zero Trust Core Tenets
1) Network Access Control
In this section, we review the core tenets of zero trust, based The authentication of all entities should happen before
on the works of DeCusatis et al. [23], Rose et al. [2], allowing them further access to organisation assets. This can
Samaniego and Deters [24], and Jericho [10]. be achieved by proper network segmentation and access
control policy.
1) Access Segmentation 2) Traffic Filtering
Every access to resource must be appropriately segmented, This category of capabilities is about the enforcement of
such as no single entity can access the entire network or even network segmentation and prevention of unauthorized
a large part of it. Furthermore, a certain number of (least connections. For this purpose, firewall technologies along
possible) entities must be able to explicitly access critical with IDS/IPS and traffic analysis tools can be applied. In
data. This extends and applies particularly to administrators, addition, monitoring of unusual traffic behaviour should be
where in most cases they tend to preserve unlimited and implemented.
uncontrolled access throughout the whole network. 3) System Access Control
2) Universal Authentication This category of capabilities deals with the file and user
All entities, either user and devices or applications and access controls. These can be implemented by using login
workloads, having any form of interaction with the corporate agents, different cryptographic controls, such as full disk
network must be authenticated regardless of their network encryption.
location (internal or external). 4) Application Segmentation
3) Encrypt as Much as Possible Similar to network segmentation, application must be
ZTA assumes breach (i.e., the worst-case scenario), isolated from each other and user access should be explicitly
therefore, network is always considered hostile, and trust limited to only those applications needed to successfully
cannot be inherently granted. That said, one must always perform their duty.
 5) Application Execution Control while the data plane contains the components that support
This deals with the prevention of unwanted, potential data transmission.
malicious or applications that have not been previously
1) Device Agent / Gateway-Based Deployment
authorised and approved to be executed. Application
In this deployment model, the Policy Enforcement Point
whitelisting is a common control for this category.
(PEP), as shown in Figure 4, requires to be highly integrated
6) Operational and Forensic Analysis
with two major components, the endpoints (which can be e.g.,
This deals with analysing the systems and resources for a laptop, a desktop computer in a remote location, or a
evidence of breach or detect anomalies. The most common
handheld device) and the resource or application(s) subject to
means that support this include host-based intrusion detection
a user access request. In Figure 4, the model called “Device
systems, application monitoring, honeypots/honeynets,
Agent / Gateway-Based Deployment” [2] is presented, where
forensic tools, vulnerability scanners, external/internal threat
the endpoints are tagged as “Enterprise System” and the
intelligence, penetration testing and red teaming, Security
subject as “Data Resource”.
Information and Event Management (SIEM) related tools,
To implement this model, an agent is required to be
breach and attack simulation, behavioural analytics, as well
installed. Hence, this model has the maximum overall control
as APT detection/prevention platforms.
because the agent acquires real time contextual information
7) Policy Engine / Policy enforcement
for the endpoints and their users, as well as the resources they
Vulnerability analysis and prioritisation, operational risk are trying to access, at any given time. As a result, a decision
analysis and behavioural analysis should occur in this by the control plane can be made at any point and the
category. necessary configuration of data plane is instant and highly
In the following Figure 3, we draw a reference capabilities accurate.
blueprint. We take a notional bank information technology
architecture as an example, and we map the different
capabilities of ZT on this architecture.

Figure 3 - ZTA capabilities - core controls reference

E. Zero Trust Models Nonetheless, a drawback of this model is the de facto

requirement of agent installation in the endpoint and the full
In this section, we discuss three zero trust deployment
integration of the data resource with the gateway. A good
models, presented in the NIST standardisation document [2].
example of this model is Google’s BeyondCorp
These deployment models are high-level concepts, without
implementation of ZT [13] [26].
any real-world implementation examples. Each model is
composed of a control plane and a data plane. The control
plane includes the policy engine and policy administrator,
 Figure 4 – NIST Device Agent/Gateway-Based Deployment [4]. Figure 6 – NIST Resource Portal-Based Deployment [4].
2) Enclave-Based Deployment In Table 1, we summarize each of the zero trust deployment
Similar to the previous case, this model again requires an models based on the four discussed characteristics.
agent to be installed on the user’s endpoint, however, the PEP
is placed in front of an enclave of resources. Unlike the first Table 1 – Advantages / Disadvantages & Attribution Table of
NIST’s ZT deployment models
deployment model, there is no requirement for a tight
integration between the resources, which is one of the Contextual
advantages of the “Enclave-Based Deployment” model [2] NIST PEP Agent Control/ information /
Deployment Location Required Data plane fine grained
(as shown in Figure 5). A disadvantage of this deployment Model Integration access
model, however, is that a zone of implicit trust is controls
automatically created amongst the gateway and the resources, Device Attached to System & Highly
Agent/Gateway- resources resource Tight available – yes
and therefore, the context creation advantage as seen Based
previously is lost. In front of Limited
Enclave-Based resources System Medium availability –
not possible
Resource In between Limited to
Portal-Based system & None Loose zero – not
resources possible

III. EXISTING ZERO TRUST APPROACHES

In this section, we discuss the existing zero trust approaches.
We start with the approaches from previous research and
continue with real world ZTA implementations suggested by
different companies.
A. Theoretical Approaches and Concepts
Cloud and mobile computing introduced and enabled
the borderless networks; therefore, it is imperative to re-
design cyber security controls accordingly and not just for the
Figure 5 – NIST Enclave-Based Deployment [4]. corporate perimeter. DeCusatis et al. [23] identified the
limitations of the existing best practices with regards to
3) Resource Portal-Based Deployment
network segmentation. Grounded on steganographic overlay,
In this model, the PEP is neither integrated with the user
they discussed a novel architecture acting as an enabler to a
endpoint nor the application or service [2], as shown in Figure
zero-trust approach. Technically, such was possible due to the
6. A gateway is positioned accordingly in the network
so-called steganographic overlay embedding authentication
corridor, and responsible for controlling the access to the
tokens within the first-packet authentication and TCP
subject resources. The advantage of this deployment model is
requests. An experiment deployment was demonstrated in
that it is agentless, namely, no special software is required to
both the traditional and cloud computing environments.
be installed on the user’s endpoint(s), and the subject
application(s) / resource(s) does not require any Rose et al. [2] first provided an abstract definition of
modifications. However, its drawback is the loss of fine- ZTA, while also contributed to the common body of
grained access control towards the resources or applications, knowledge by specifying general deployment models and use
and hence, limited to zero contextual information can be used cases where ZTA could enhance an overall cyber security
to make context aware decisions. The first example of this posture of an enterprise. Embrey [27] identified the top three
model was presented by Forrester [19] utilizing technologies factors driving ZTA adoption, and stresses that while
such as VLANs and next generation firewalls (NGFW) to adopting ZTA there needs to be enhanced security and policy
achieve segmentation (we will discuss more about it in controls at the user and device level as well. Mehraj and
section III.B). Banday [28] proposed a conceptual zero trust strategy
explicitly for cloud environments. Their efforts also Figure 7 demonstrates the access and traffic flow along
emphasising in trust establishment and further trust with the components of the BeyondCorp zero trust
challenges applicable to cloud computing. Yan and Wang implementation. Such approach can be mapped back to the
[29] performed a survey on zero trust components and key Device Agent/Gateway-based deployment model proposed
technologies. They also applied some of the subject by NIST (see section II.E).
technologies and related them to specific scenarios, in order
to highlight further advantages of ZTA.
Keeriyattil studied the whitelisting approach [30],
however, on the network level. The ingress and egress traffic
of a virtual NIC card were examined against a given list of
firewall policies. Based on the whitelisting concept, if no
matching rule is found for a specific traffic flow, then the
packet is simply dropped. Using specific technologies (e.g.,
VMWare NSX) the author demonstrated how only the traffic
Figure 7 - BeyondCorp Traffic/Access Flow & Components [13].
that is checked against specific records would be allowed,
otherwise, it would be rejected. Mital [31] discussed DLT At first, it is imperative to notice that the public network
and blockchain technology’s features that would be compared to the internal network within Google’s building
applicable to zero trust approach. Specifically, the author have absolutely no difference when it comes to user and
discussed how the immutability property of blockchain could devices privileges, hence both are unprivileged. Moreover,
help in establishing higher integrity standards. In addition, the device authentication on the internal unprivileged network is
elimination of a possible single point of failure in ZTA could performed via the 802.1x standard through a RADIUS server.
help with maximizing the availability, due to the “inherent” Prior accessing that network, all users follow the same flow
relevant attributes of DLT. through a single sign on (SSO) mechanism, that provides
B. Real World ZTA Implementations authentication to resources. An innovative element is their
Identity Aware Proxy (IAP), which works well and
In this section, we review four relevant commercially synergistically with context-based access control, ultimately
available zero trust architectures, namely, Google’s complementing this zero-trust model. Their access is not
BeyondCorp [13], Forrester NGFW/ZTX [11], Cloud implicitly allowed for the user / device being simply part of
Security Alliance (CSA) Software-Defined Perimeter (SDP) the corporate network. Quite the reverse, access is explicitly
[32], and VMWare NSX [30]. Those architectures are the granted based on context and policy.
current dominating real-world deployment models [33],
The BeyondCorp model authenticates the users on the
unlike the previous high-level architectures from NIST in
application layer of the network. There is a heavy reliance on
section II.E.
this aspect since most of their applications and services are
1) Google’s BeyondCorp web-based. Furthermore, Google applications are mostly
Following a hacking campaign by the Anonymous group developed internally, combined with their own existing SSO
named Operation Aurora in 2009 [34], Google came up with system led to a successful implementation of the new
the BeyondCorp project. Based on a detailed report published architecture. However, companies without heavy internal
by McAffee labs on the lessons learned from Operation development or heavy reliance on web-based services, will
Aurora [35], the attackers were able to access the internal probably require a different model. Google also productized
network. The attackers specifically targeted the sources of BeyondCorp’s tested model as BeyondProd, which is a cloud
intellectual properties and used the compromised system as a native security solution [36].
starting point (also known as “jump-point”) to move laterally. Overall, if an organisation has multiple publicly exposed
Consequently, Google’s primary goal was to remove services with several cloud-based applications accessed by
the inherent trust acquired by its users and devices, due to public users, then this model is likely to work well. However,
their placement (physical or electronic) within the corporate we note that Google only applies this on their cloud
network. Moreover, in case a user or device was infrastructure and currently no other organization offers a
compromised, as seen during Operation Aurora, a secondary similar solution. As a result, applying the BeyondCorp model
goal was to minimize the probability of an adversary moving for a non-cloud environment is not straightforward, and the
laterally through the network and compromising further relocation of several core management controls may be
entities. required.
Three core tenets were the derivative of the first 2) Forrester (Zero Trust Extended) ZTX
whitepaper of BeyondCorp in 2014 [13]: Kindervag coined this zero-trust concept back in 2010 at
Forrester [19]. In this model, as depicted in Figure 8, a
• The services a user/device can access must not be centralized segmentation engine was able to manage and
determined by a specific connection and especially isolate the enterprise network into multiple MCAP (micro
the location of the connection. core and perimeter) segments, when and where appropriate.
• All access to services must be determined based on As such, it was enabled to enforce traffic rules in between
contextual information. MCAPs. Figure 8 shows the next-generation firewall
• All access to services must be authenticated, (NGFW) being used as a segmentation engine to form
authorized and encrypted.
multiple MCAPs. Such approach can be mapped back to the We can find some similarities between this model and the
“Resource Portal” model outlined by NIST (see section Forrester ZTX approach. For instance, SDP acts as a central
II.E.3). firewall performing network segmentation, like NGFW
described in the previous paragraph. SDP undertakes the role
of an overlay network beyond the current network
infrastructure. User authentication and identity verification
happen at the SDP server, therefore, instantly creating a VPN
tunnel between the subject resource and the authenticated
user. Figure 9 shows the described SDP controller connection
handling process, which eventually results in a direct VPN
tunnel between hosts.

Figure 8 - Forrester's NGFW used as segmentation engine forming

MCAPs [19].

As highlighted in Table 1, in reference to the Resource

Portal model, the required changes in components for this Figure 9 - SDP Reference Workflow [32].
model prior implementation are minimum or near zero,
hence, it is an attractive choice. However, this model makes The key difference, however, relies on how a VPN and SDP
use of the information available in the data packets, in order manage and establish the overall trust towards users and
to enforce trust. This approach is less “granular” compared to devices. For instance, traditionally in case of VPN, once the
the architectures that integrate tightly with endpoints and user and/or device is authenticated and authorized, he/she can
services. Another drawback of this approach is that the users, access the vast majority of the network with trust being
cannot be directly authenticated with the NGFW implicitly applies by default taking into account the network
segmentation engine. Namely, the segmentation engine is not location. On the other hand, once a user and/or a device
capable of enforcing policies based on the contextual authenticates itself with the SDP controller, a set of role-
information of users and devices. based access, attributes and eventually context of user trust is
enforced. An important advantage of SDP, nonetheless, is the
Many organisations are already deploying an enclave- elimination of the integration with the subject resource (or
based architecture, which is a good match for this zero-trust application). At the same time, installation and configuration
architecture. The architecture is likely to be the best for and on both resource and endpoint are still required.
the easiest to deploy in a BYOD (bring your own devices) or
an IoT (internet of things) environment, because the devices Conclusively, SDP is a fairly new concept being
can be placed within their own enclave or MCAP. However, continuously improved and the relevant market offerings are
an important shortcoming is that the access control in this not yet mature enough, at least at the time of this writing,
model can be less fine grained than in other architectures. In though they have reached a point where enterprise adoption
addition, there is a dependency of further integration with can be achieved with no major issues or complications.
other technologies such as identity and access management Moreover, SDP does not require a costly integration with the
(IAM), device management systems or a VPN, to achieve the applications, due to its inherent architecture principle.
same security levels as other architectures. Finally, SDP can be seen as a perfect match for organisations
3) Software-Defined Perimeter with several IoT systems, or Operational Technology (OT) in
The concept of Software-Defined Perimeter (SDP) was general, since the gateway can act on behalf of the mentioned
introduced by a non-profit organization called the Cloud devices. Barcelo et al. [37] and Anggorojati et al. [38]
Security Alliance (CSA) in 2013 [32]. Several SDP based confirmed this via the SDP and IoT/OT integration and heavy
solutions have been developed since then and have been testing.
proven for large organisations and holds its fair share into the 4) VMWare NSX
market. Using the NIST high level models to conduct a The deployment based on VMWare NSX is another real
mapping, SDP would match the Enclave-Based Deployment world ZTA deployment. However, this model is mainly
Model. Namely, an agent is required on the endpoint and the referring to organisations that already leverage the virtual
service, however, there is no integration with the target desktop infrastructure (VDI) [30].
resource or the target application, therefore, the agent itself
can be considered as taking the role of a gateway on the The model matches the Device-Agent/Gateway Deployment
service side. model, although it assumes that all resources are based on
virtualized systems, namely, the applications hosted in virtual
servers. A reference zero trust architecture using NSX is Resource
Portal-
In between
system & None Loose
Limited to zero
– not possible
NGFW /
Forrester
shown in Figure 10. Based resources ZTX

IV. OPEN QUESTIONS AND CHALLENGES

The primary goal of ZTA, if properly implemented, is to
perform identity-based access control fine-graining [2], in an
ultimate effort to prevent the increasingly severe risk of lateral
movement. There are multiple access control types such as
role-based and attribute-based access controls, however, ZTA
performs access control on the identity of the user, namely,
identity-based access control. Moreover, the zero-trust
approach primarily focuses on protecting assets and
network/user accounts, workflows and services, rather than
network segments. The location of the network (e.g., home,
Figure 10 - Reference ZTA using NSX [30]. work, or a public place) is deemed irrelevant within the ZTA
context and its relationship to the overall security posture of
As depicted in Figure 10, the workflow of this the resource.
architecture starts with a user authentication step on the VDI
server. Thereafter, a remote session on a virtual desktop is However, the above argument comes with a fundamental
established and presented to the user. The virtual server and assumption that the core components of a ZTA should be able
the virtual desktop are the two core components of the NSX to contextualise users access requests before granting them
access to enterprise resources. Namely, before a user is
based approach. In this case, NSX acts as a firewall where
granted access to corporate resources, several conditions must
policy decisions and trust management are performed and
be met, such as the operating system version, software patch
enforced throughout the network as a whole and in multiple levels, IP address or source/origin, the time of a request (e.g.,
points. Hence, the administrative team is enabled to perform is it between 09:00-17:00?). Such information is of course
access control fine graining in manifold segments, which can subject to each corporate policy and the context. This
be also referred to as micro-segmentation [39]. approach can be effectively implemented if we assume
A major advantage of this approach is the concept of extremely locked-down devices, or fully managed devices like
virtualized desktop itself. Particularly, the administrator in BeyondCorp [13], where only corporate Google
group who control the full virtual desktop fleet, have the Chromebook devices are granted access, without support for
ability to refresh or rebuilt it on a frequent basis (e.g., at the BYOD capability [13].
night). Therefore, if we assume an adversary compromising It should be noted, however, that currently the majority of
an endpoint via one of the most common adversary enterprises run Windows as their core operating system [41],
methodologies, such as phishing or spear phishing etc., that may run a wide variety of legacy, outdated applications
establishing persistent foothold will be highly unlikely. This and/or middleware increasing the security risk. Determined
would disrupt the so-called cyber kill chain [40] at a very attackers have previously demonstrated how the traditional
early stage. On the other hand, most organisations are already perimeter-based defences can be bypassed, for example, with
deploying a highly virtualized model and switching into a malware and phishing attack, to gain foothold in the enterprise
VDI-based architecture would be costly. In contrast to SDP network. Once a device is compromised, the operating system
discussed previously, this model may be a bad choice for IoT (and the device that runs it) can no longer be trusted, since a
systems due to the virtualization requirement in the sensors potential malware in the operating system kernel can tamper
with ZTA security health checks, which are part of the context
and OT.
build by ZTA. This eventually results in bypassing the
Finally, building upon Table 1, we map the existing zero trust fundamental control implemented in a ZTA.
architectures to the NIST deployment models, and provide a As a result, enterprises that implement one of the current ZTA
unified Table 2 with summarised information. models might mistakenly trust user devices (or endpoints), as
attackers are still able to compromise those devices and
Table 2 - Real-World ZTA implementations mapped to NIST thereafter ride the already authenticated user’s session to
deployment models.
perform several user and device centric malicious activities
Contextual Real- other than lateral movement. A good example is the attack
NIST
Deploym
PEP
Location
Agent
Required
Control/
Data plane
information /
fine grained
World
Impleme
approach like the MITRE ATT&CK navigator [42] that
ent Integration access controls ntation includes malicious payload execution, privilege escalation,
Model
and defence evasion to compromise user devices. In case the
Device Attached to System & Highly Google’s compromised device belongs to an administrator, the inherent
Agent/G resources resource Tight available – yes BeyondC
ateway- orp & impact of such scenario is of critical severity. Considering the
Based VMWare
NSX
above, one could argue that ZTA creates a false sense of
security, particularly, when it comes to endpoints, since
In front of Limited Software enterprises that begin ZTA adoption are encouraged to allow
Enclave- resources System Medium availability – Defined
Based not possible Perimete access to corporate resources via BYOD, unmanaged or even
r
personal devices, by relying on a mixture of health and
security checks and context that can be eventually forged Each participating IDS in the DCIDS architecture has two
once a user device is compromised. core functional units:

V. POTENTIAL APPROACHES • Detection unit, responsible for the data collection

locally.
A. Distributed Collaborative Intrusion Detection
• Correlation unit, which is a segment of the
Deploying Intrusion Detection Systems (IDSs) is a well- overall distributed correlation architecture.
known approach to effectively detect intrusions based on the
anomaly caused by malicious or compromised devices. It is worth noting that, despite the benefits brought into the
Hence, it is one of the most promising solutions for the defensive landscape from the DCIDS, the overall attack
problem discussed in section IV. However, implementing a surface increases in these architectures, because of their
standalone IDS is often insufficient in case of large distributed nature. The attackers would have more IDS nodes
companies due to the large number of false positives and to target in order to start working their way towards a stealthy
negatives. Shortcomings of standalone IDS systems have foothold establishment, or simply covering their tracks on a
been studied by Fung et al. [43], Duma et al. [44] and Weizhi single endpoint. The main security issue identified in the
context of DCIDS is the integrity of the data shared among the
et al. [45], as also referenced in the related work paragraph.
IDS nodes, which can be incorrect/incomplete either because
As a result, Distributed Collaborative Intrusion Detection of lack of trust (e.g., an IDS node refuses to reveal sensitive
Systems (DCIDSs) have been proposed to improve the data) or the data is sent by a compromised IDS node. Ensuring
efficiency and availability of standalone IDS. integrity of the shared data is crucial, and block-chain as well
Collaborative Intrusion Detection Systems (CIDSs) as the distributed ledger technology can be a promising
or Collaborative Intrusion Detection Networks (CIDN) are approach, which we will discuss in the next section.
deployed to eliminate limitations [46] of standalone IDSs.
CIDSs consists of cooperating IDSs, utilising collective Another issue needs to be considered in the DCIDS
knowledge to achieve superior intrusion detection accuracy. context is the dissemination of the alert messages and shared
Furthermore, Distributed Collaborative Intrusion Detection data. Garcia et al. [49] in their study, proposed a DCIDS
architecture that correlates alerts from participating nodes
Systems (DCIDSs) serve various additional IDS abuse cases,
effectively via a secure multicast infrastructure, which
such as Distributed Denial of Service (DDoS) attacks. Wu et demonstrated a great capability to detect attacks against and
al. [47] showed that in practice, compared to a standalone IDS possibly even prevent them. Their architecture was based on
setting, CIDS can reduce the number of missed alarms (to 1 local IDS, called “prevention cells”, which detect and record
of 7 cases), and completely eliminated the number of false the attack patterns locally. Thereafter, the alert messages were
alarms in their test system based on Snort, Libsafe, and a new exchanged between the local IDSs to achieve a more effective
kernel level IDS called Sysmon. detection rate.
In order to make this work as accurate and relevant to ZTA
in relation to APTs context as possible, we focus our review To cope with advanced persistent threats (APTs), Dash et
on three pillars of DCIDS. Specifically, (1) architecture, (2) al. [50] proposed a collaborative host-based IDS approach,
alert correlation and (3) alert trustworthiness. which detects network intrusion using distributed probabilistic
inference. Based on a hierarchical architecture, they proposed
1) Architecture: From the architecture perspective, three core components in their system. Local Detectors (LDs),
DCIDS can greatly reduce the rate of false positives and being the first component, which serves as a local version of
negatives by correlating and analysing multiple suspicious the IDS, analysing the endpoint state and relevant local traffic
evidences from different sources or sensors throughout the patterns. Secondly, the Global Detectors (GDs) captures the
network. There is also potential to decrease computational global views of potential attacks by analysing information
costs, because of intrusion detection resources can be shared gathered through LDs, using a probabilistic model. Finally,
between networks. An overview of distributed CIDS is the information sharing system (ISS) acts as a communication
enabler between LDs and GDs via a gossip protocol.
shown in Figure 11 [48].
In addition, approaches such as binary classifier are
utilised by LDs to analyse both the incoming and outgoing
traffic of the potentially compromised host. Alerts would be
triggered if a pre-configured threshold is crossed. The state of
the overall security of LDs is constantly transmitted to
randomly selected GDs at pre-defined intervals through ISS.
Finally, the GDs provide global monitoring based on the
analysis from data collected from LDs.
This approach could be adapted for the zero-trust context.
In particular, if an APT had compromised an endpoint within
a notional ZTA, or when the attacker had established foothold
on the network, performed data exfiltration from the endpoint,
and stole available credentials, it would be detected, however,
relatively late since data and credential exfiltration would
have taken place.
Figure 11 - DCIDS Reference Architecture [48].
 2) Alert Correlation: In this part, we categorise the 3) Alert Trustworthiness: Within a distributed
DCIDSs based on the alert correlation approaches. These collaborative intrusion detection network, it is imperative to
generally include the filter-based approach, the multi-stage maintain trust between nodes, while also trust the alerts
approach, the similarity-based approach, and the attack generated by participating nodes. As we mentioned
scenario-based approach. In the first case, a prioritisation of previously, DCIDS can be particularly effective if IDSs share
alarms takes place based on the criticality of the protected intrusion-related information with each other, however, the
system, while in the second case, the correlation of alerts is validity and completeness of the information is crucial. In
based on the causality of former and latter alarms. The third some cases, this is prevented either by compromised devices,
case is simply based on the similarities of alarm attributes. or the lack of willingness to share, in case of different
Finally, the attack scenario-based approach is based on pre- organisations. INDRA, a DCIDS approach based on peer-to-
defined attack scenarios. peer (P2P) infrastructure by Janakiraman et al. [55], proposes
A. Dain and Cunningham [51], presented an algorithm that an authentication based solution for the alert messages.
can combine the alerts produced by heterogeneous IDSs via Specifically, message authentication based on digital
a probabilistic approach. This approach utilises three signatures is used to provide a reasonable level of assurance
variations of Bayesian networks (BNs) for effectively that alerts originating from a trusted node, by utilising a
detecting network intrusions. Specifically, in the presented central certification authority to produce node’s credentials.
algorithm, the CIDS consisting of multiple types of IDSs However, this does not guarantee the completeness and
generating alerts, were converted into acceptable machine- correctness of the messages in case of compromised nodes or
readable format and then stored in a standard SQL database. benign nodes refusing to provide complete information.
Thereafter, the algorithm read the database, categorize and Finally, with regards to scalability, the central certification
relate the alerts into attack scenarios. As soon as new alerts are authority can be subject to bottleneck as the participating
generated in the IDSs and stored in the database, they are
automatically checked against the constructed attack nodes increase.
scenario(s).
Chen and Yeager built upon the previous work and proposed
Cuppens and Ortalo [52] introduced LAMBDA, an attack the use of “Web of Trust” between participating nodes [56].
description language aiming to correlate alerts from various The concept is based on reputation of the nodes, and the
IDSs to CIDSs. LAMBDA can be used to specify the pre- and collection, exchange and evaluation of all information
post-condition of a target system. Namely, how a system looks between participants are fully “transparent” to the nodes.
like before an attack scenario is launched, and how is it Participating nodes can build, over time, a certain level of
affected after a successful attack scenario. As a result, a wide
reputation among themselves, which is ultimately the essence
range of alerts are generated and processed by LAMBDA that
of P2P trust relationships. This approach indeed amplifies the
eventually are correlated to draw an outcome regarding an
ongoing attack scenario or not. During the specification, the trust bonds required for the purpose of alert broadcasting, in
overall attack scenario is considered, including all possible case of an intrusion, and as such it seems promising.
threat events and threat types applicable to the target system. However, there is still a problem requiring further study. For
In addition, the overall steps for detecting an attack, which example, if a peer takes the necessary time to build high
might be different on each attack scenario, and the verification reputation among the IDS network, then it could potentially
of an attack are also considered. broadcast malicious or forged alerts.
Cheung et al. [53] proposed CAML, a modelling language Recently, blockchain has been widely investigated as an
to detect various attack scenarios. Compared to LAMBDA, approach to achieve message integrity in a decentralised or
CAML is also based on the specification of the pre and post
distributed network environment. Blockchain can be either
condition of the subject system. However, it allows lower-
level specification and therefore, lower level of details are public or private depending on the group of authorised users.
delivered to the IDS nodes. In addition, deep diving into the In the following, we review how blockchain has been used to
lower-level specifications provides CAML an advantage ensure or improve the integrity of the shared alert messages
when it comes to accurate decision making with regards to an and enforcing trust in the area of intrusion detection.
ongoing attack.
B. Blockchain Based Intrusion Detection
Considered that we are discussing APT attacks, the higher
level of detail, the higher chances for the attack to be detected. At the time of writing this paper, research on the
Such assumes a proper false positives mechanism being in application of blockchain in intrusion detection systems is
place, however. still in its infancy and continue to be an emerging and
promising area. Blockchain has been investigated mainly in
Templeton and Levitt [54] proposed another attack
the context of CIDSs, in order to achieve the integrity of the
specification language for DCIDS, named JIGSAW. Similar
to LAMBDA and CAML, their work is heavily based on pre information shared among the IDSs.
and post conditions of an attack and the subject target system.
Major differentiation with CAML and LAMBDA, however, Blockchain is closely related to the distributed ledger
is that JIGSAW intends to describe specific attacks on the technology (DLT) that refers to a database where records of
threat event-type level, namely attacks, rather than attack decentralised and transactional data are stored in a sequence
scenarios. (not necessarily grouped in blocks), in a continuous ledger
spread through a network and across multiple locations. On
the other hand, blockchain, can be considered as a DLT
subset, in which batches of transactions are held in blocks, with a system and are not willing to agree on a trusted third
which in turn are linked with hash pointers in a chain [57]. In party. To ease the decision process, Wüst et al. [58] provided
continuation, each block contains the hash of the previous a decision flowchart as shown in Figure 12, to help determine
block in the chain, and therefore, the integrity of each data set whether blockchain addition would be the correct technical
in the chain is preserved. solution of a problem.
1) Blockchain types
By drawing an analogy between blockchains and databases
(as Wüst et al. [58]), we can refer to the blockchain
participants as readers and the validators (or appender). A
reader refers to a role or entity who can read, analyse or audit
the blockchain. A validator (appender) on the other hand,
describes a role or entity that is involved in the consensus
protocol, collects transactions into a block and finally
appends the block to the blockchain. Based on the roles of the
participants, we can differentiate between permissionless and
permissioned blockchains.
a) Permissionless blockchains
In permissionless blockchains, the peers can leave or join the
network at any moment, whether they possess the role of a
reader or a validator. One of the most interesting parts of this
setup, is the elimination of a central entity that controls Figure 12 - Blockchain decision flowchart [58].
membership overall. Therefore, the written content onto such
blockchains is readable by any peer at any given moment. As The authors also provided performance evaluation among
of today, however, there are implementations utilising permissioned, permissionless blockchains and a typical
cryptographic primitives that allow for a permissionless database. The results are summarised in Table 3 below, which
blockchain to hide privacy related information. For instance, can help system designers with decision making on
the Zerocash [59], which acts as a privacy preserving version blockchain implementations.
of Bitcoin. Two prevalent examples of permissionless
blockchains include Bitcoin [60] and Ethereum [61]. Table 3 - Properties of permissionless / permissioned blockchains
b) Permisioned blockchains: and central database
In this setup, a central authority is performing the decision Permissionless Permissioned Central
making and relevant attribution to peers participating in read blockchain blockchain Database
or append roles within the blockchain. Most prevalent Throughput Low High Very High
examples of permissioned blockchains at the moment are Latency Slow Medium Fast
Number of readers High High High
Hyperledger Fabric [62] and R3 Corda [63]. This approach is Number of validators High Low High
leaning towards enterprise grade adoption, due to its inherent Number of untrusted High Low 0
implementation of a central authority managing peers and users
their identities. Considering the highly sensitive and Consensus Mainly PoW BFT None
confidential use case of blockchain in cyber security and mechanism Some PoS protocols
Centrally managed No Yes Yes
specifically in intrusion detection and prevention, it becomes
evident that the permission blockchain implementation has
In general, blockchain adds complexity, which is the use of
better attributes than the permissionless.
consensus mechanisms. Therefore, using a central database
It is well-known that blockchains impose computation or centralised systems enhance the performance in the sense
overhead and extra cost (due to the hash calculations and of throughput and latency. On one hand, one can refer to
consensus protocol), and the security of private blockchains Bitcoin, which capable of handling 7 transactions per second
greatly depends on the number of the participants. While and can extend up to 66 with no compromise in security. On
private blockchains have been implemented by businesses in the other hand, VISA, which operates a highly centralised
different sectors such as banks, healthcare, and supply system can handle throughput of approximately fifty
chains1, mainly to verify the integrity of contracts and secure thousand transactions. Conclusively, there is a trade-off
access to health data, it is still important to see that there are between scaling and throughput. Specifically, for a
blockchain enabled IDS, how well that system would scale to
some cases when blockchain is not a suitable solution.
Specifically, in our case, we raise the following question: a large number of validators with thousands of hashes as
inputs (e.g., detection rules) and how much throughput such
which conditions would make blockchains suitable for the
system would produce in a pre-defined amount of time. Such
intrusion detection context, and in general cyber security use
cases? The “obvious” answer is when multiple entities lack trade-offs should be taken into account when we try to add
trust in each other, while at the same time want to interact blockchain element into intrusion detection.

1
Forbes, Blockchain 50,
https://www.forbes.com/sites/michaeldelcastillo/2020/02/19/blockchain-50/
(accessed March 2021)
 Centralization Decentralized Partially Centralized
Centralized
2) The consensus mechanisms: Assuming a blockchain
Double Possible Difficult N/A
enabled IDS, where multiple nodes, acting as peers, are Spending
spread throughout the network for monitoring, gathering and Attack
data correlation purposes they have to reach consensus Scalability Not Scalable Scalable Scalable
Memory Significant due Significant due Less than PoW
somehow. There must be an effective, practical, dependable, Requirement to public to public or PoS
efficient, continuous and secure mechanism to guarantee that ledger ledger
each and every single event and alert are received and sent Security Attack with Attack with May have a
respectively, as well as are real and unaltered while all peer 51% is 51% not single point of
possible possible failure
members concur to the status of the ledger. That said, there
are several consensus mechanisms providing such
capabilities each one with their different attributes [64]. 3) Related works on blockchain enabled IDSs:
a) Proof of Work (PoW): This serves as the most A universal architecture that incorporates CIDS with
popular consensus protocol, broadly used in cryptocurrencies permissioned blockchain has been described by Alexopoulos
and was first introduced in Bitcoin. PoW introduces the roles et al. [65], together with a design decisions analysis process
of the miners, those are responsible to solve cryptographic required when implementing such architecture. In this
puzzles while competing each other for a reward. However, architecture, a set of intrusion related alerts are defined as
PoW is probably not suitable for blockchain enabled IDS transactions within the blockchain. Then, utilising the
(within a private enterprise environment) as the concept of consensus protocol, all collaborating IDS nodes can verify
rewarded miners would introduce huge security gaps and the validity of the transactions prior conveying them into a
trust loopholes in the system. block. Eventually, the stored set of alerts shall be tamperproof
b) Proof of Stake (PoS): In this case, there is no within the blockchain. However, neither implementations
competition between the miners. Instead, PoS relies on the details are provided in their paper nor relevant results, hence,
validators, who are pseudo-randomly selected to validate a the idea remains explicitly theoretical. Similar work at a
block. In addition, it introduces the so-called stake tokens, theoretical level was published by Weizhi Meng et al. [66],
where in order to participate in this sequence, the validator where they studied upon data and trust management
enrols by staking some of his/her own tokens. Therefore, challenges on current IDS architectures. Afterwards, the
participants are rewarded based on the number of staked authors delivered the first review corresponding to the
tokens. Considering the blockchain based IDS use case, such intersection of intrusion detection systems and blockchain
mechanism would create a bottleneck as participants with technology, while also outlined the prospective application of
high amount of tokens staked have automatically better such collaboration. One of the key conclusions they made
chances of being elected for validation, which in turn creates was that blockchain technology can greatly assist in
a security risk when we talk about events, rules and alerts of enhancing an intrusion detection system’s core tasks such as,
an IDS. trust computation, exchange of alerts and data sharing.
c) Practical Byzantine Fault Tolerance (PBFT): In A step further in detecting adversaries via blockchain
PBFT, a predefined group of individuals act as validators. enabled cyber defence capabilities was performed by Li et al.
Participants have to reach consensus when a new event [67]. They studied specifically the integrity property in CIDS,
occurs while at the same time, they have to verify that no data by considering a highly likely scenario which we often
has been modified during the event transmission. If 2/3 of the encounter nowadays, namely, insider attacks such as a
participants reach consensus, then the decision is considered malicious node generating forged signatures and then sharing
final. it throughout peers. If that scenario becomes a reality,
d) Proof of Burn (PoB) & Proof of Capacity (PoC): intruders could potentially remain undetected, which would
Similar to the above-mentioned mechanisms PoB & PoC are greatly affect the effectiveness of a CIDS. In addition, the
operating under a similar scheme, they are mining and reward authors utilised the blockchain technology to solve the
based mechanisms which are an inherent disadvantage when subject issue in a verifiable manner, and evaluated the results
it comes to enterprise grade adoption for the use case of a via a so-called CBSigIDS development, a generic framework
blockchain enabled IDS, due to confidentiality and integrity
reasons [64].
Finally, to summarise this section, a comparative
evaluation of the most widely implemented consensus
mechanisms can be found in in Table 4 (Hazari et al. [64]).

Table 4 - Consensus mechanisms comparative evaluation.

Consensus PoW PoS BFT

Mechanisms
Energy Requires high Requires less Requires less
Consumption amount of energy energy
energy consumption consumption
Advanced Required Not Required Not Required
Hardware
Requirement
of CIDS based on blockchain. Figure 13 depicts the proposed trusted source of logging, which in turn can further enhance
blockchain based CIDS framework, in a high-level overview. and maximise trust in auditing.

Figure 13 - High level overview of blockchain based CIDN [66]

On the other hand, a more practical approach was One of the core principles of ZTA, namely, “never trust
proposed by Golomb et al. [68], namely, the collaborative IoT but verify”, seems to match greatly with blockchains’
anomaly detection (CIoTA) framework. This is a lightweight inherent attribution where every transaction must be
framework that leverages blockchain technology to validated, consensus must be achieved at all times, while
accomplish collaborative and distributed anomaly detection. ledger’s immutability seals integrity.
In this framework, Blockchain is being utilised to
C. ZTA and Decentralised Blockchain-based IDS
incrementally feed an anomaly detection model and establish
convergence
consensus amid IoT devices. Eventually, the authors created
their own distributed IoT simulation platform consisting of In this section, we build upon the ZTA core principle of
48 Raspberry Pi’s and evaluated and demonstrated CIoTA’s assuming breach (see section II.C) to discuss how
ability to enhance security via blockchain. Blockchain-based IDS can be employed. For this discussion,
we use an example of a ZTA enabled notional bank network,
Conclusively, we can say that the previous works where we assume that a single endpoint has been
validate, mainly at the theoretical level, the potential of compromised via a spear phishing attack. As per our review
blockchain enhancing intrusion detection. There is, however, (see section II), and the abovementioned assumption, the
a practical demonstration of the above conclusion performed lateral movement is highly unlikely once ZTA is in full force
by Golomb et al. [68] with CIoTA, although it is focus and [69], adhering to all principles and all mandated controls in
scope is limited on IoT. Moreover, an IoT network is different place. However, the endpoint itself remains compromised,
from an enterprise network in the sense that it provides less together with the already authenticated and authorised
control maturity compared to the current applicable control sessions of the subject user in the endpoint. Moreover, the
frameworks and standards. Besides the great potential of adversaries can abuse the authenticated and authorised
using blockchains in intrusion detection (and prevention), sessions of the user and extend their attack to the systems in
there are probably other advantages that require further reach of the subject user.
research. For instance, a blockchain enabled IDS can be a
Distributed collaborative intrusion detection systems as
reviewed in section A, would be able to detect such attack via
a plethora of methodologies. Specifically, attack scenario- This is very different from ZTA and blockchain, where
based approach for alert correlation when utilised by DCIDs both run on a borderless and decentralised manner
is an effective and efficient approach for adversary detection. respectively. Since there is no perimeter on both ZTA and
A major shortcoming can be identified, however, with this blockchain, security comes from efficient and effective
approach. In the context of ZTA and APTs, (1) the adversaries management of trust. In fact, for blockchain, security comes
characteristically use legitimate tools in malicious manner, from the incredible amount of repetition because every node
and (2) they also utilise advanced evasive techniques against is being asked to keep the same copy of the ledger and
the standard controls (e.g., signature based / heuristic-based periodically reach majority consensus on what the proper data
anti-virus etc.) Therefore, the attack scenarios can fluctuate in that ledger should be. As such, the amount of work that an
greatly. Until the attack scenario-based approach eventually attacker would have to do is practically impossible, if
constructs the relevant and matching scenario, adversaries adversaries wanted to change, hack, or alter the ledger. That
probably have already established stealthy foothold into the said, it seems that blockchain and ZTA can complement each
network, deeming the detection process ineffective, again, in other in various use cases, since both share at least some
a ZTA context. In addition, the integrity of DCIDs nodes is fundamental principles.
questionable as per the literature review in certain scenarios.
Our assumption of an APT compromising an endpoint, is Determined attackers, also known as APTs, with the
subject to the same scenario, since a determined adversary necessary knowledge and resources have demonstrated their
would likely try to influence the integrity of a node and/or ability to compromise various endpoints with ease, and plant
tamper with logs and audit trails to render the attack invisible. malware to establish foothold into corporate networks. The
different ZTA deployment models (see section II.E and
Blockchain based intrusion detection as reviewed in implementations (see section III) are a great instrument in the
section B, greatly increases the integrity of the audit trail and hands of defenders, in their effort to prevent lateral
log files, as well as the overall integrity of the information movement. The result is a highly secure, trust-less and
stored in the blocks themselves. Additionally, blockchain borderless architecture with fine grained identity-based
could potentially enhance the efficiency of intrusion detection
access controls always seeking to verify. However, the
by extending the immutability aspect on the context of each
and every single identity. Specifically, zero trust security endpoints are proven to be the Achilles heel of ZTA.
health checks can be used to create the so-called endpoint Adversaries can potentially tamper with ZTA’s security
context. This context, then, could be further fortified by the health checks once an endpoint is compromised, therefore
distributed ledger technology to achieve integrity. ZTA, leveraging the already authenticated and authorised user’s
DCIDS and the blockchain technology seem to have a great session.
intersection and many potential use cases. In fact, some use Blockchain technology can enhance ZTA
cases could even be extended beyond detection, to implement implementations in several use cases. As described in section
blockchain based prevention capabilities.
V.C, a blockchain-based intrusion detection system could
VI. SUMMARY AND DISCUSSION help in amplifying the detection capability. At the same time,
it is possible to fortify the backend storage of relevant logs &
As we can see, ZTA and blockchain take a different
audit trails in the blockchain, providing immutability.
approach on trust management, security and architecture
Blockchain based authentication could also be used to
overall, in contrast to traditional, perimeter-based approach.
Table 5 shows the previously mentioned elements intersection enhance remote working. For instance, a blockchain based
in ZTA and blockchain, in contradiction to the traditional layer could be added on top of a software defined perimeter
perimeter-based approach. (SDP) to strengthen the endpoints integrity. Enhancing the
prevention capability with blockchain is of equal, if not more,
Table 5 - ZTA & Blockchain Intersection elements interest. Combining a blockchain-based intrusion detection
Traditional Zero Trust Blockchain
and prevention system would ultimately augment ZTA onto
Perimeter-Based Architecture the endpoints, significantly enhancing detective and
Architecture
preventive functions.
Overall Centralized Decentralized Decentralized
Approach

Architectural Perimeter-Focused Borderless / Distributed VII. CONCLUSION

focus Distributed
In this paper, we provided a systematic state-of-the-art review
Infrastructure Trusted or semi- Untrusted or trust Untrusted
trust level trusted in some cases but verify in
on zero trust and zero trust architectures, which are relevant
some cases and emerging research and development areas. Based on 43
papers in the ZTA literature, we reviewed several aspects of
the zero trust approaches and open questions. In particular,
In perimeter-based approach, we have the element of
we discussed the main differences between traditional
centralisation and the architectural focus is to protect the
perimeter. Meaning that trusted data and assets are placed perimeter-based models and zero trust approaches. In
behind a very strict perimeter, assuming that anyone and addition, the core tenets and core capabilities of the zero-trust
anything inside that perimeter is trusted, either partially or concept were presented, with different existing theoretical
fully, to access those resources. Ultimately, maximum effort and real-life implementations of zero trust architectures.
is being put forth into making sure that adversaries will not be Thereafter, based on examples, we discussed the potential
able getting beyond that perimeter, while at the same time security problems with current zero trust architectures, and
authorised and authenticated users can still access the data and outlined some potential and promising approaches that can be
resources behind it. used to tackle those problems. Specifically, one of the
approaches we explored is the possibility of adapting we-mean-by-blockchains-are-trustless-aa420635d5f6.
blockchain, together with distributed collaborative intrusion [Accessed 17 October 2020].
detection systems (DCIDSs) to verify the integrity of the [11] P. J. Taylor, T. Dargahi, A. Dehghantanha, R. M.
endpoints in a zero-trust architecture. Based on the state-of- Parizi and K.-K. Raymond Choo, “A systematic
the-art in this area, we conclude that blockchains and DCIDSs literature review of blockchain cyber security,”
can play a relevant part in zero trust architectures, however, Digital Communications and Networks, vol. 6, no. 2,
their implementation requires serious consideration due to pp. 147-156, May 2020.
computation overhead and the trade-off between security and
usability. [12] M. Tayyab, B. Belaton and M. Anbar, “ICMPv6-
Based DoS and DDoS Attacks Detection Using
Machine Learning Techniques, Open Challenges, and
REFERENCES Blockchain Applicability: A Review,” IEEE Access,
vol. 8, no. 170529, pp. 13-14,16-17, 28 September
2020.
[1] R. Rapuzzi and M. Repetto, “Building situational
awareness for network threats in fog/edge computing: [13] M. Zhou, L. Han, H. Lu and C. Fu, “Distributed
Emerging paradigms beyond the security perimeter collaborative intrusion detection system for vehicular
model,” Future Generation Computer Systems, vol. Ad Hoc networks based on invariant,” Computer
85, pp. 235-249, August 2018. Networks, vol. 172, no. 107174, pp. 12-14, 8 May
2020.
[2] E. GIlman and D. Barth, Zero Trust Networks:
Building Secure Systems in Untrusted Networks 1st [14] W. Li, Y. Wang, Z. Jin, K. Yu, J. Li and Y. Xiang, “g,
Edition, A. Courtney and V. Wilson, Eds., O'Reilly, Challenge-based CollaborativeIntrusion Detection in
2017, pp. 21-29,51-62,65-90,93-101,113-125,137- Software Defined Networking: An Evaluation,”
171,173-207,209-215. Digital Communications and Networks, vol. 10, no.
1016, pp. 4-6, 19 September 2020.
[3] J. Forum™, “The Open Group,” May 2007. [Online].
Available: [15] C. Cunningham, “forrester.com,” Forrester Research,
https://collaboration.opengroup.org/jericho/command Inc., 27 March 2018. [Online]. Available:
ments_v1.2.pdf. [Accessed October 2020]. https://go.forrester.com/blogs/next-generation-access-
and-zero-trust/. [Accessed October 2020].
[4] N. S. A. (NSA), “U.S. Department of Defense,” 25
February 2021. [Online]. Available: [16] J. G. Grimes, “acqnotes.com,” June 2007. [Online].
https://media.defense.gov/2021/Feb/25/2002588479/- Available:
1/- http://www.acqnotes.com/Attachments/DoD%20GIG
1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_ %20Architectural%20Vision,%20June%2007.pdf.
UOO115131-21.PDF. [Accessed February 2021]. [Accessed October 2020].
[5] R. Ward and B. Beyer, “BeyondCorp - A new [17] R. Ward and B. Beyer, “BeyondCorp: A New
approach to enterprise security,” BeyondCorp, vol. 39, Approach to Enterprise Security,” Usenix, vol. 39, no.
no. 6, pp. 6-11, 2014. 6, pp. 6-10, December 2014.
[6] D. Teixeira, A. Singh and M. Agarwal, “Evade [18] L. Cittadini, B. Spear, B. Beyer and M. Saltonstall,
Antiviruses, bypass firewalls and exploit complex “BeyondCorp: The Access Proxy,” Security, vol. 41,
environments with the most widely used penetration no. 4, pp. 28-33, 2016.
testing framework,” in Metasploit Penetration Testing [19] B. Osborn, J. McWilliams, B. Beyer and M.
Cookbook, Third Edition, Birmingham - Mumbai, Saltonstall, “BeyondCorp: Design to Deployment at
Packt Publishing Ltd., 2018, pp. 264-269, 188-229. Google,” Security, vol. 41, no. 1, pp. 28-34, 2016.
[7] S. Rose, O. Borchert, S. Mitchell and S. Connelly, [20] J. Peck, B. Beyer, C. Beske and M. Saltonstall,
“nist.gov,” 20 August 2020. [Online]. Available: “Migrating to BeyondCorp: Maintaining Productivity
https://doi.org/10.6028/NIST.SP.800-207. [Accessed While Improving Security.,” Security, vol. 42, no. 2,
17 10 2020]. pp. 49-55, 2017.
[8] M. Campbell, “Beyond Zero Trust: Trust Is a [21] V. Escobedo, B. Beyer, M. Saltonstall and F.
Vulnerability,” Computer Society, vol. 53, no. 10, pp. Żyźniewski, “BeyondCorp 5: The User Experience,”
110-113, 2020. Security, vol. 42, no. 3, pp. 38-43, 2017.
[9] M. Pincheira, M. Vecchio, R. Giaffreda and S. S. [22] H. King, M. Janosko, B. (. E. Beyer and M.
Kanhere, “Exploiting constrained IoT devices in a Saltonstall, “BeyondCorp 6: Building a Healthy
trustless blockchain-based water management Fleet.,” Security, vol. 43, no. 3, pp. 24-30, 2018.
system,” in 020 IEEE International Conference on [23] J. Kindervag, S. Balaouras and L. Coit, “Build
Blockchain and Cryptocurrency (ICBC), Toronto, Security Into Your Network’s DNA: The Zero Trust
Canada, 2020. Network Architecture,” Forrester Research, Inc.,
[10] P. Kasireddy, “medium.com,” 3 February 2018. Cambridge, MA 02139 USA, 2010.
[Online]. Available: [24] C. Smith, “Understanding concepts in the defence in
https://medium.com/@preethikasireddy/eli5-what-do- depth strategy,” in IEEE 37th Annual 2003
International Carnahan Conference onSecurity
 Technology, 2003. Proceedings., Taipei, Taiwan, [37] M. Labs, “Wired,” 3 March 2010. [Online].
2003. Available:
[25] D. Pallais, “Microsoft,” Microsoft, 18 September https://www.wired.com/images_blogs/threatlevel/201
2019. [Online]. Available: 0/03/operationaurora_wp_0310_fnl.pdf. [Accessed 26
https://www.microsoft.com/en-us/microsoft- October 2020].
365/blog/2019/09/18/why-banks-adopt-modern- [38] Google, “BeyondProd: A new approach to cloud-
cybersecurity-zero-trust- native security,” 2020.
model/#:~:text=Many%20banks%20today%20still%2 [39] M. Barcelo, A. Correa, J. Llorca, A. M. Tulino, L. J.
0rely,protect%20data%20from%20malicious%20attac Vicario and A. Morell, “IoT-Cloud Service
ks.&text=So%2C%20whether%20an%20insider%20a Optimization in Next Generation Smart
cts,data%2. [Accessed 23 October 2020]. Environments,” EEE Journal on Selected Areas in
[26] C. DeCusatis, P. Liengtiraphan, A. Sager and M. Communications, vol. 32, no. 12, pp. 4077-4090, 25
Pinelli, “Implementing Zero Trust Cloud Networks December 2016.
with Transport Access Control and First Packet [40] B. Anggorojati, P. N. Mahalle, R. N. Prasad and R.
Authentication,” in 2016 IEEE International Prasad, “Capability-based access control delegation
Conference on Smart Cloud (SmartCloud), New model on the federated IoT network,” in The 15th
York, NY, USA, November 2016. International Symposium on Wireless Personal
[27] M. Samaniego and R. Deters, “Zero-Trust Multimedia Communications, Taipei, 2012.
Hierarchical Management in IoT.,” in 2018 IEEE [41] S. Keeriyattil, Zero Trust Networks with VMware
International Congress on Internet of Things (ICIOT), NSX, Berkeley, CA: Apress, 2019, pp. 173-177.
San Francisco, CA, USA, 2018.
[42] E. M. Hutchins, M. J. Cloppert and R. M. Amin,
[28] Marketsandmarkets, “Zero-Trust Security Market by “Lockheed Martin Corporation,” Lockheed Martin
Solution Type (Data Security, Endpoint Security, API Corporation, 5 May 2015. [Online]. Available:
Security, Security Analytics, Security Policy https://www.lockheedmartin.com/content/dam/lockhe
Management), Deployment Type, Authentication ed-martin/rms/documents/cyber/LM-White-Paper-
Type, Organization Size, Vertical, and Region - Intel-Driven-Defense.pdf. [Accessed October 2020].
Global Forecast to 2024,” Marketsandmarkets, 2019.
[43] NetMarketShare, “NetMarketShare.com,”
[29] B. Embrey, “The top three factors driving zero trust NetApplications.com, 17 October 2020. [Online].
adoption,” Computer Fraud & Security, vol. 2020, no. Available: https://netmarketshare.com/. [Accessed 17
9, pp. 13-15, 22 September 2020. October 2020].
[30] S. Mehraj and T. M. Banday, “Establishing a Zero [44] MITRE, “The MITRE Corporation,” MITRE, 18
Trust Strategy in Cloud Computing Environment,” in October 2020. [Online]. Available: https://mitre-
2020 International Conference on Computer attack.github.io/attack-navigator/enterprise/.
Communication and Informatics (ICCCI), [Accessed 18 October 2020].
Coimbatore, India, 2020.
[45] C. J. Fung, O. Baysal, Z. Jie, I. Aib and R. Boutaba,
[31] Y. Xiangshuai and W. Huijuan, “Survey on Zero- “Trust Management for Host-Based Collaborative
Trust Network Security,” in Artificial Intelligence and Intrusion Detection,” in DSOM 2008: Managing
Security. ICAIS 2020. Communications in Computer Large-Scale Service Deployment, Berlin, Heidelberg,
and Information Science., Singapore , 2020. 2008.
[32] S. Keeriyattil, “Microsegmentation and Zero Trust: [46] C. Duma, M. Karresand, N. Shahmehri and G.
Introduction.,” in Zero Trust Networks with VMware Caronni, “A Trust-Aware, P2P-Based Overlay for
NSX., Berkeley, CA, Apress, 2019. Intrusion Detection.,” in 17th International Workshop
[33] R. Mital, “IMPROVING TRUST IN A ZERO on Database and Expert Systems Applications
TRUST ARCHITECTURE (ZTA),” Getting it right - (DEXA'06), Krakow, Poland, 2006.
Collaborating for mission success, vol. 10, no. 4, p. 2, [47] M. Weizhi, L. Wenjuan and K. Lam-For, “Design of
June 2020. intelligent KNN‐based alarm filter using knowledge‐
[34] J. Koilpillai and N. A. Murray, “Cloud Security based alert verification in intrusion detection,” in
Alliance,” CSA, 5 May 2020. [Online]. Available: Security and Communication Networks 8(18), 2015.
https://cloudsecurityalliance.org/software-defined- [48] A. Khraisat, I. Gondal, P. Vamplew and J.
perimeter/. [Accessed October 2020]. Kamruzzaman, “Survey of intrusion detection
[35] Gartner, “Gartner Research,” 4 March 2020. [Online]. systems: techniques, datasets and challenges,”
Available: Cybersecurity, vol. 20, no. 2, pp. 50-62, 17 July 2019.
https://www.gartner.com/teamsiteanalytics/servePDF? [49] Y.-S. Wu, B. Foo, Y. Mei and S. Bagchi,
g=/imagesrv/media-products/pdf/Qi-An-Xin/Qi-An- “Collaborative Intrusion Detection System (CIDS): A
Xin-1-1OKONUN2.pdf. [Accessed October 2020]. Framework for Accurate and Efficient IDS,” in
[36] C. Tankard, “Advanced Persistent threats and how to Computer Security Applications Conference, 2003.
monitor and deter them.,” Network Security, vol. Proceedings. 19th Annual, 2004.
2011, no. 8, pp. 16-19, August 2011.
[50] V. Z. Chenfeng, C. Leckie and S. Karunasekera, “A [63] V. Buterin, “ethereum.org,” 19 March 2021. [Online].
survey of coordinated attacks and Available: https://ethereum.org/en/whitepaper/.
collaborativeintrusion detection,” Computers & [Accessed March 2021].
Security, no. 29, pp. 124-140, 29 June 2009. [64] Hyperledger, “Hyperledger,” March 2020. [Online].
[51] J. Garcia, F. Autrel, J. Borrell, S. Castillo, F. Cuppens Available: https://www.hyperledger.org/wp-
and G. Navarro, “Decentralized publish-subscribe content/uploads/2020/03/hyperledger_fabric_whitepa
system to prevent coordinated attacks via alert per.pdf. [Accessed 22 March 2021].
correlation.,” in Sixth international conference on [65] R3, “R3.com,” August 2019. [Online]. Available:
information and communications security, Berlin, https://www.r3.com/reports/corda-technical-
Heidelber, 2004. whitepaper/. [Accessed 22 March 2021].
[52] D. Dash, B. Kveton, J. M. Agosta, E. Schooler, J. [66] S. S. Hazari and Q. H. Mahmoud, “Comparative
Chandrashekar, A. Bachrach and A. Newman, “When evaluation of consensus mechanismsin
Gossip is Good: Distributed Probabilistic Inference cryptocurrencies,” WILEY, 2019.
for Detection of Slow Network Intrusions.,” in he
[67] N. Alexopoulos, E. Vasilomanolakis, N. R. Ivánkó
Twenty-First National Conference on Artificial
and M. Mühlhäuser, “Towards Blockchain-Based
Intelligence and the Eighteenth Innovative
Collaborative Intrusion Detection Systems,” in
Applications of Artificial Intelligence Conference.,
International Conference on Critical Information
Boston, Massachusetts, USA, 2006.
Infrastructures Security, 2018.
[53] O. Dain and R. K. Cunningham, “Fusing A
[68] W. Meng, E. Wolfgang Tischhauser, Q. Wang, Y.
Heterogeneous Alert Stream Into Scenarios.,” in
Wang and J. Han, “When Intrusion Detection Meets
Applications of Data Mining in Computer Security.,
Blockchain Technology: A Review,” IEEE Access,
vol. 6, Boston, MA., Springer, 2002.
vol. 6, no. 1, pp. 10179-10188, 15 March 2018.
[54] F. Cuppens and R. Ortalo, “LAMBDA: A Language
[69] W. Li, S. Tug, W. Meng and Y. Wang, “Designing
to Model a Database for Detection of Attacks.,” in
collaborative blockchained signature-based intrusion
International Workshop on Recent Advances in
detection in IoT environments,” Future Generation
Intrusion Detection., Berlin, Heidelberg, 2000.
Computer Systems, vol. 96, pp. 481-489, July 2019.
[55] S. Cheung, U. Lindqvist and M. Fong, “Modeling
[70] T. Golomb, Y. Mirsky and Y. Elovici, “CIoTA:
multistep cyber attacks for scenario recognition.,” in
Collaborative IoT Anomaly Detection via
Proceedings DARPA Information Survivability
Blockchain,” in Proceedings of workshop on
Conference and Exposition., Washington, DC, USA,
Decentralized IoT Security and Standards (DISS),
USA, 2003.
Negev, 2018.
[56] S. J. Templeton and K. Levitt, “A requires/provides
[71] R. A. Cormier, N. T. Spurgeon, D. L. Schuh, P. A.
model for computer attacks.,” in Proceedings of new
Smyton, R. S. Swarz, F. C. Wendt and G. Rebovich
security paradigms workshop., 2001.
Jr, mitre.org, Bedford, MA: MITRE Corporate
[57] R. Janakiraman, M. Waldvoger and Q. Zhang, “Indra: Communications and Public Affairs, 2014, pp. 167-
a peer-to-peer approach to network intrusion detection 174.
and prevention,” in WET ICE 2003. Proceedings.
[72] M. Coole, J. Corkill and A. Woodward, “Defence in
Twelfth IEEE International Workshops on Enabling
Depth, Protection in Depth and Security in Depth: A
Technologies: Infrastructure for Collaborative
Comparative Analysis Towards a Common Usage
Enterprises, 2003., Linz, Austria, Austria, 2003.
Language,” in Proceedings of the 5th Australian
[58] R. Chen and W. Yeager, “Poblano A Distributed Security and Intelligence Conference,, Perth, Western
Trust Model for Peer-to-Peer Networks.,” IEEE, Australia, 2012.
2001.
[73] NetMarketShare, “NetMarketShare.com,”
[59] G. Verdian, P. Tasca, C. Paterson and G. Mondelli, NetApplications.com, 17 October 2020. [Online].
“Quant Network,” 31 January 2018. [Online]. Available: https://netmarketshare.com/operating-
Available: https://www.quant.network/wp- system-market-
content/uploads/2020/07/Quant_Overledger_Whitepa share.aspx?options=%7B%22filter%22%3A%7B%22
per-Sep-1.pdf. [Accessed 17 November 2020]. %24and%22%3A%5B%7B%22deviceType%22%3A
[60] K. Wüst and A. Gervais, “IACR,” 2017. [Online]. %7B%22%24in%22%3A%5B%22Desktop%2Flapto
Available: https://eprint.iacr.org/2017/375.pdf. p%22%5D%7D%7D%5D%7D%2C%22dateLabel%2
[Accessed March 2021]. 2%3A%22Trend%22%2C%22attributes%22%3A%2
[61] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. 2share%22%2. [Accessed 17 October 2020].
Miers, E. Tromer and M. Virza, “Zerocash: [74] M. Steichen, S. Hommes and R. State, “ChainGuard
Decentralized Anonymous Payments from Bitcoin,” — A firewall for blockchain applications using SDN
in IEEE Security & Privacy Symposium, 2014. with OpenFlow,” in Principles, Systems and
[62] S. Nakamoto, “bitcoin.org,” 2009. [Online]. Applications of IP Telecommunications (IPTComm),
Available: https://bitcoin.org/bitcoin.pdf. [Accessed Chicago, 2017.
22 March 2021].
[75] L. Zhichum, Y. Chen and A. Beach, “Towards Conference on Trust Management (IFIPTM), Berlin,
Scalable and Robust Distributed Intrusion Alert Heidelberg, 2014.
Fusion with Good Load Balancing.,” in Proceedings [79] K. Uttecht, “Zero Trust (ZT) Concepts for Federal
of the 2006 SIGCOMM Workshop on Large-Scale Government Architectures,” Department of Homeland
Attack Defense (LSAD), 2006. Security (DHS) Science and Technology Directorate
[76] T. A. Tuan, “A Game-Theoretic Analysis of Trust (S&T), Lexington, Massachusetts, 2020.
Management in P2P Systems,” in 2006 First [80] F. Valeur, G. Vigna, C. kruegel and R. A. Kemmerer,
International Conference on Communications and “Comprehensive approach to intrusion detection alert
Electronics, Hanoi, Vietnam, 2006. correlation,” Transactions on Dependable and Secure
[77] L. Wenjuan, M. Yuxin and K. Lam-For, “Enhancing Computing., vol. 1, no. 3, pp. 2-8, July-September
Trust Evaluation Using Intrusion Sensitivity in 2004.
Collaborative Intrusion Detection Networks: [81] P. Ning, Y. Cui and D. S. Reeves, “Constructing
Feasibility and Challenges,” in 2013 Ninth attack scenarios through correlation of intrusion
International Conference on Computational alerts,” in Proceedings of the 9th ACM conference on
Intelligence and Security, Leshan, 2013. Computer and communications security, 2002.
[78] L. Wenjuan, M. Weizhi and K. Lam-For, “Design of
Intrusion Sensitivity-Based Trust Management Model
for Collaborative Intrusion Detection Networks,” in
Proceedings of the 8th IFIP WG 11.11 International