Zero Trust Architecture

Abstract

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

Private and Trustworthy Distributed Lending Model Using Hyperledger Besu

“…In addition to the built-in features of private Ethereum blockchain such as immutability, reliability, and security [2,36,66], this lending model confirms the trustworthiness by implementing privacy group patterns for each group of loan participants on Besu Ethereum client [4,11]. The model of our malicious detection algorithm is partially connected to zero trust architecture, where it reduces the uncertainty in access management [60]. The MaliciousDetector smart contract is acting as a policy decision point to monitor and track API requests to allow users to enter into a trustworthy zone [60,62].…”

“…The model of our malicious detection algorithm is partially connected to zero trust architecture, where it reduces the uncertainty in access management [60]. The MaliciousDetector smart contract is acting as a policy decision point to monitor and track API requests to allow users to enter into a trustworthy zone [60,62].…”

Multi-Access Edge Computing Architecture, Data Security and Privacy: A Review

“…trust domains [47]- [49]. At the same time, considering the flexibility of the MEC architecture, achieving mutual authentication with anonymity and untraceability are crucial for data security and user privacy [50], [51]. Authentication methods include single-domain authentication [41], crossdomain authentication [52], and the SDN-based handover authentication scheme [53].…”

“…However, edge networks might exfiltrate sensitive information and rich network context information, such as client status information, traffic statistics and local network conditions that are used by applications to offer context-aware optimization [12]. • Privilege escalation: Privilege escalation arises when a bad actor exploits a design flaw, bug, or configuration error in an operating system or application to gain elevated access to protected resources that would typically be restricted to that user [51], [104]. The malicious user can then use the newly acquired unauthorised privileges to steal confidential data, run administrative commands or deploy malware, and potentially do severe damage to server applications [5], [13], [77].…”

“…Secure access to applications and devices remains a challenge that involves the use of adaptive policies, trust in user identities, and device trustworthiness [47]. Trust management should continuously reassess the posture of applications, users, and devices [51]. The original design trusted every entity in the ecosystem, i.e., users, devices and services.…”