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.