Resolve and prioritize cybersecurity research problems for distributed observing systems

Statement of Work Project Title: Blockchain Distributed Ledger for Space Resource Access Control Future Earth-observing (EO) space systems will provision control over distributed assets to dynamically compose functional capabilities (sensing, processing, transmission, etc.) within a federation of systems. For example, commercial firms Planet Labs and Capella host web-based APIs that allow customers to task and retrieve imagery from their satellite constellations. However, managing an increasing variety of functional capabilities among a growing set of providers poses a challenge to control access to space-based resources with autonomous operating modes. A distributed ledger (blockchain) may provide a robust and transparent record of resource provision requests and grants in a distributed system. The New Observing Strategies Testbed (NOS-T) is a computational platform for prototyping and maturing new EO technology [1]. It provides a publish-subscribe interface using the Message Queuing

Telemetry Transport (MQTT) protocol to exchange messages among member applications (nodes) as components of an EO system. Test case executions use messages to test new EO concepts and operating modes in a virtual environment. This project proposes to apply a distributed ledger (blockchain) within the context of a distributed EO system. The blockchain is represented as one or more nodes that participate in a test case execution. Other applications representing components of the federated EO system (e.g., satellite operators, customers, etc.) interact with the blockchain application to request and grant access to resources. Blockchain technology enables zero-trust cybersecurity protections for data stored in immutable ledgers where users (members) can trust that data comes from authentic instruments. This data stored in ledgers provides significant protection making it much more difficult for adversaries to gain illicit access. Each participating organization authenticates users through API functions, establishing different roles that categorize access through fully automated governance policies that appropriately limit access to data and services. All organizational users and/or instruments must be invited, authenticated and characterized by role before joining the network in a permissioned blockchain. In order to bring zero-trust identity to space based instruments and application services, we propose to build a secure instrument registration and a blockchain-based access control overlay to help manage assets and services (resources) using a consensus based transaction protocol. We plan to use a hyperledger permissioned blockchain capability to support user/instrument registration that will enable transaction processing for users and instruments. All registered instrument IDs, application and/or user IDs will be recorded in the immutable ledgers by each participating organization. After instruments are authenticated, attribute-based access control (ABAC), role-based access control (RBAC), and connectors will be implemented between instruments and the blockchain network. The RBAC rule will be used to categorize users into different roles, such as operators or guests. For example, only governors can update transactions, and guests can only query transactions or send transactions. ABAC will be used to categorize instruments or resources into different attributes based on the data types in accordance with requirements. The target ecosystem will maintain the listed functionality: ? Maintenance of all data transaction information in blockchain and improved data quality/provenance through distributed ledgers of audit logs. ? Zero-trust instrument registrations. ? Increased security through fine-grained attribute-based access control. A designed access control rules for various instruments. ? API functionality for different UI interfaces. ? A gRPC connector between an instrument and blockchain network. When MQTT protocol exchanges messages among member applications (nodes) as components of an EO system, its broker can call a function of a smart contract API (by generating a transaction) to verify registered instruments or users in the blockchain. This latter records the requested versifications on the blockchain and demonstrates that the broker has started the authentication request. When an NOS-T manager application orchestrates test run executions, it should have smart contracts to query the blockchain ledgers for registered instruments, users, resource access controls. Assume that over the classic MQTT software, the broker has high-level software called IoT application, which is in charge of carrying out some operations of the authentication procedure or checking the resource access controls.