Developed by: University of Southampton

Service Ledger

Analysis

The Service Ledger (SL) is a blockchain-as-a-service platform that offers programmable blockchain-enabled services that apply in several application scenarios.

Use case example :

enabling the sharing of security information between different entities/organisations

The organisations involved can share CTI information to improve the awareness and the defence against threats and malicious activities

Service Ledger platform is used for sharing CTI coming from:

  • the security and monitoring features of the SIEM tools
  • the local authorities CERT/CSIRTs that aim to share CTI (like IoC and TTPs)
  • Advantages of a solution based on blockchain
  • Blockchain technology distributes trust and preserves strong integrity on shared CTI
  • SL permits privacy preserving security information sharing
    allowing the deployment of private, permissioned blockchains – specific Communities of Interest (CoIs)

Service Ledger is build on top of the Algorand blockchain platform

Algorand[1] is one of the most valuable blockchain platforms. It’s a secure, decentralised, and scalable solution

Service Ledger Main components (see Figure below) :

  • Configuration manager
    Algorand deployer and configurer
  • Privacy manager
    policy-based privacy rules definition (to be finalised in WP5)
  • Data access control manager
    Programmable access control rules for CTI read/write operations
  • Orchestrator
    Connects the blockchain node with either a permissioned or permission-less Algorand network
  • Blockchain explorer
    user friendly dashboard for the blockchain inspection
  • Smart contract application manager
    deployer of Algorand’s client applications that interact with the blockchain

Presentation of the Service Ledger

Service Ledger embeds a software module for the CTI sharing

  • Algorand’s programmable smart contract is able to persist and transact the blockchain CTI based on the STIX 2.0[2] standard
  • TAXII 2.* protocol embedded in SL for the exchange of STIX CTI
    • CTI consumers can access CTI resources on SL over HTTPS
    • CTI producers can publish (and share) CTI resources on SL over HTTPS

Technical

The Service Ledger (SL) is a middleware blockchain-enabled platform that offers programmable services that directly or indirectly interact with one or more decentralised applications.

SL enables MEs/SMEs to collaborate and share CTI over a fully decentralised network without any centralised owner of data. The overview of the infrastructure is depicted in the Figure below. The Organisations (MEs and SMEs) and the Local Authorities share CTI and cybersecurity-related events via SL who indeed represents a gateway to the decentralised network.

High level overview of the SL CTI sharing platform architecture

SL uses a decentralised data store system (to be defined between IPFS – InterPlanetary File System, and Solid Project) to store data. Stored data will then be linked to a blockchain network that will distribute trust among participants, and guarantee security, immutability and reliability of data shared.

Each Organisation and Local Authority runs a SL instance to participate in the decentralised network. the Figure below illustrates the technical architecture of a single SL instance. The SL instance embeds a Web Application Server developed with the Node.js framework (we leave open the possibility of migrating to Django for compatibility with other tools). SL provides a data encryption service that manages the encryption of CTI data that needs to be shared. This component can be integrated with the IBM SDS tool. The web application is also provided with a PostgreSQL database to store user-related information.

Detailed architecture of a SL instance

SL embeds a TAXII 2.1 server (component not decided yet – might be the OASIS implementation of TAXII Medallion) to enable the sharing of CTI in STIX format, using the TAXII standard. The TAXII server exposes REST API that will be invoked by users via the Client Interface and forward data to the server via REST API.

The primary SL client interface is a web-based client application (ReactJS) that enables users to interact with SL’s functionalities. In addition, users can interact with SL via ad-hoc REST APIs.

SL’s users could have either the “admin” role for administration and configuration functionalities, or “user” role for common usage. The management of users is still uncertain due to the fully decentralised nature of the architecture. The usage of third party trusted authorities for identity management (e.g., Keycloak) represents a single point of control that should be avoided in a fully-decentralised network. A better solution will be the implementation of a DAO – Decentralised Autonomous Organisation via encryption rules governed by the blockchain network. Nevertheless, this functionality is ambitious and of difficult implementations, and in case of difficulties a classic centralised (or semi-centralised) approach will be used for identities management and access control rules.

The Service Ledger server application directly communicates with an embedded blockchain node and data store node respectively for:

  1. (i) the secure store of sharing events,
  2. the persistence of data.

Service Ledger relies on the Algorand blockchain platform for its principal functionalities of data sharing:

An Algorand node is embedded into SL and configured by SL instance administrators. The Algorand node instance maintains a wallet with all the blockchain accounts and their public/private key pairs and communicates via the public Algorand blockchain via the embedded APIs. The SL’s blockchain functionalities are implemented via the Algorand SDK (Javascript and Python sdks).

The data store functionality has not been implemented yet. It will be a peer-to-peer decentralised storage network and SL will embed one Data Store node to persist data accordingly. The principal candidates for building such a decentralised storage network are IPFS and Solid Project.

Service Ledger will be deployed as a multiservice containerised architecture (using Docker). Each SL instance will run 5 docker containers:

  • The SL application
    deployed within a NodeJS server exposing the endpoint REST APIs and the frontend client interface accessible via web browser;
  • A TAXII server
    listening for incoming connections from the frontend APIs, that communicates data straightforward to the server application;
  • A PostgreSQL database
  • Algorand node
    full docker image: Algorand sandbox;
  • The Data store node
    docker image (to be defined).

References

[1] https://www.algorand.com

[2] https://docs.oasis-open.org/cti/stix/v2.0/cs01/part1-stix-core/stix-v2.0-cs01-part1-stix-core.html