# Addressing ZSM Security Issues with Blockchain Technology
## 6 Assessment of the Architecture  
We examine how the proposed solution tackles the security issues mentioned in Section 3.2 one-by-one in the sequel and also tabulate them in Table 1.  
As new NPs join the ZSM framework, the number of blockchain nodes increases and the network grows, assuming that each NP hosts/deploys at least one blockchain node. The private and permissioned characteristics of the network minimize the possibility of the existence of a malicious player which is also tackled by the applied consensus mechanism. Since the blockchain network is private and permissioned, we assume that a trusted governance entity is responsible for registering the NPs to the network. Automatically, a trust layer among competitive NPs is created and the _trust issue among multiple management domains_ (security issue 1) highlighted by the ETSI team is addressed. To reduce the _vulnerabilities of management functions_ (security issue 2) we take advantage of the immutability feature of Smart Contracts (SCs). We propose the use of SCs for the implementation of the management functions defined in [34]. The rationale behind this is the following: an SC is an immutable deterministic piece of code stored and used in the blockchain network. An SC's functionality cannot be undermined, and its content cannot be tampered with as it is stored in the ledger. When an SC is created, it is related to a unique blockchain address used by other entities in the network in order to execute its functions. Additionally, an SC is a set of promises that are executed when predefined conditions are met. This feature allows SCs to execute functions automatically without human intervention. Given the _security concerns regarding the vulnerability of management functions_ in ZSM, the use of SCs for their implementation is ideal. Moreover, the ability to control an SC's visibility to other blockchain participants is supported in various blockchain solutions and can be used to increase the confidentiality of a transaction or the non-disclosure of SC's information in multitenant environments, if this is required. As a result, we can achieve _access control to sensitive information_, such as management functions, stored in the network. Blockchain can also be used to monitor the behavior of AI/ML by storing the decisions in the form of transactions. The traceability feature of blockchain allows us to examine the decisions of AI/ML components during their operation and identify any suspicious activity. At the same time, the credibility of the decisions' history cannot be questioned since it is a valid blockchain transaction registered in the ledger. Furthermore, the training of mathematical models used in these technologies is based on datasets that should be safeguarded. Although the first thought would be to store datasets in the blockchain, the scalability issue of this technology forces us to design an alternative solution. Datasets which usually include enormous amounts of information can be stored in Inter Planetary File System (IPFS) distributed structures and the link that points to the data location can be stored in the form of a hash as a valid transaction. As a result, the origin and quality of data are guaranteed, and an _extra layer of security is added to the AI/ML components of ZSM_. Finally, with respect to the complexity, we adopt the definition presented in [32] where the complexity level of the system is defined based on the number of parts comprising the system. According to the definition, a system that uses a smaller number of parts is less complex than a system that uses a higher number of parts. In this paper, the solutions proposed by the standardization team use many different technologies and techniques (e.g., NESAS, Adversarial ML Threat Matrix) to tackle security issues. Our approach aims to eliminate these issues by using only blockchain technology.