Fig. 3. A centralised DR system.
Assume the DR system described in Figure 3. It is obvious that a local
infrastructure is required to supply processing power for several
components; moreover, there is no encryption between the communication
and privacy methods. The various components communicate data over public
endpoints, which, despite considerable protection, are vulnerable to
attackers. Also, keep in mind that adding new components or scaling
existing ones may necessitate more labor and processing capacity
Finally, communicating with a different DR system is not possible in
this architecture because there is no semantic interoperability layer to
translate the payloads, and this other DR system may use different
communication protocols, complicating communications even if both DR
systems use the same standard.
The DR system depicted in Fig. 3 may be decentralised in various local
infrastructures using the CIM, as depicted in Fig. 4. The processing
power required by each DR component in this new design is also dispersed
among several local infrastructures, making the overall DR system more
efficient.
Fig. 4. A decentralised DR system using the CIM.
Furthermore, all DR components are only accessible via the XMPP network.
Joining this network necessitates the creation of authentic XMPP
credentials and certificates by the XMPP network administrator. As a
result, the various components are better shielded from possible
threats. Furthermore, all conversations are encrypted from beginning to
end. It is also worth noting that communication between the CIM and the
local DR components necessitates the use of a JWT token to authenticate
the requests. Although this communication does not necessitate a robust
security strategy because local infrastructures are not publicly
accessible and are also trustworthy. The CIM’s present implementation
relies on JWT authentication; however, this might be changed by
alternative methods such as OAuth or basic authentication.
In terms of data protection, the CIMs have their own access control
list. This implies that even if an attacker could join the network, the
attacker’s CIM would be unable to share data owing to the CIMs’
distributed access control lists. Furthermore, the XMPP server may set
access control list policies across CIM groups.
The design of the DR system represented in Fig. 4 is modular, and so its
components may be scaled. When a component has a high workload, it might
be duplicated in the XMPP network to balance the former component’s
total workload. Furthermore, adding new components just necessitates
deploying them through the CIM and configuring the necessary security
and privacy parameters of the other CIMs.
From the standpoint of semantic interoperability, integrating a
component that follows a different DR standard, and thus has a different
format and model, requires only the development of the necessary
Interoperability Modules to translate the payloads that are expected to
be sent and those that are expected to be received by such a component
via the CIM.
As a result, the CIM allows DR systems to exchange data with components
designed according to multiple DR standards. Furthermore, the CIM
provides a good security framework for exchanging data with the CIM
locally using JWT tokens or remotely via the XMPP network utilizing
authentication mechanisms, end-to- end encryption, certificates, and the
access control lists that each CIM maintains.
Security in P2P networks is determined by whether the network is
centralised, hybridised, or decentralized. A centralised or hybrid
network’s security provides a single point of failure: the centralised
servers. An assault on one of these servers might compromise the
security of the entire network. A rogue node in a decentralized P2P
network can corrupt a portion of the network, but it is doubtful that a
single bad node could control the entire network. As a result,
decentralized networks are less vulnerable to assaults than centralised
or hybrid networks, although these latter two types of networks are more
suited to monitoring,
making attack detection and network recovery easier. The following are
examples of attacks that can be launched against a P2P network.
Attack against eavesdropping. Created at the network layer. By
collecting tiny packets from the network, attackers can obtain access to
data and eavesdrop on communication. TLS, as specified in the standard,
is used to protect the stream from eavesdropping.
Sybil assault. Consists of generating a huge number of bogus identities
and utilizing them to gain significant influence in the network, causing
disruption or preparing for future assaults. Configuring TLS and SASL,
as specified in the standard, helps to secure the client’s server from
direct assault or identification by third parties.
Attacks on buffer overflow. The attacker overwrites memory components,
altering network functioning and potentially destroying or exposing
data. As stated in the standard, utilizing base64 in SASL helps to
prevent against buffer overflow attacks and other implementation-based
vulnerabilities.
A denial of service attack has occurred. The most typical DoS attack is
a single node flooding the network with fake packets, which prevents or
slows network activity. When two or more nodes are participating in an
assault, it is referred to as distributed DoS. The XML stanzas18, as
indicated in the standard, assist defend the client’s server against
DDoS assaults after TLS and SASL are implemented.
Other attack kinds are conceivable. Certain KPIs can be configured to
minimize these assaults. 19 The following are the most important KPIs:
Keep track of the overall number of requests. Examine how many requests
are being processed on the network.
Keep an eye on the nodes. Determine the number of nodes in the network,
whether it drops or rises, and whether the quantity is adequate.
Requests should be monitored per node. Monitor how many requests each
node receives and sends: whether some nodes send fraudulent requests or
whether a node behaves differently at various times.
Keep track of the requests by IP address. Keep track of how many
requests are received and issued by each IP address, and use this
information to determine their geographical location.
The Node software. Examine which software versions are being utilized by
the nodes and whether these versions have known security flaws.
These KPIs may be seen in the CIMs since they are linked to an XMPP
broker that offers them. As a consequence, they may be watched for
prospective assaults.