First release of Service Ledger tool for sharing Cyber Threat Intelligence

5th July, 2022

Author Gilberto Zanfino

Within the CyberKit4SME project, one of the objectives for SMEs and MEs is to enhance their cyber situational awareness by monitoring their systems and collecting indicators about potential cyber-attacks from external malicious actors. This goes under the name of Cyber Threat Intelligence (CTI), namely the art of detecting which system asset has been compromised and its associated threat. For instance, a compromised workstation’s IP address and port, along with its alert reference, such as a ports scanning, a virus signature or the file hash of a malware. The CTI knowledge is of great value for enterprises: the more information they have, the better they can mitigate ongoing attacks and predict future ones. SMEs and MEs can thus decide to cooperate among each other by sharing their CTI data, which enables them to analyse various attack scenarios and, consequently, to perform a more accurate correlation between discovered threats.

Service Ledger

The Service Ledger (SL) is a blockchain-based platform that provides secure-by-design data storing and sharing functionalities. Differently from traditional repositories based on centralised solutions, SL employs the InterPlanetary File System (IPFS) as decentralised protocol to store data over a peer-to-peer network. The key characteristic of IPFS is to assign a file with a unique identifier, called Content Identifier (CID), and then cryptographically split the file into smaller chunks distributed on the network nodes. As privacy-preserving property, SL maintains a list of users’ public keys and encrypts any file before sending it to the IPFS network. Once a file is stored on IPFS, SL relies on the Algorand blockchain to represent its corresponding CID as a Non-Fungible Token (NFT), making it tamper-proof, verifiable and traceable.

To deal with CTI data, SL integrates the STIX and TAXII standards. The STIX is a data modelling language for representing CTI data in a structured way. The TAXII is a client-server application protocol for exchanging STIX objects over HTTPS. The following figure shows the high-level architecture and key components of SL for CyberKit4SME.
Service Ledger architecture

The SL architecture

An instance of SL contains an Algorand node and an IPFS node to respectively connect with the Algorand and IPFS networks. In addition to, it embodies a TAXII server that exposes the typical get and post APIs to share CTI data. SMEs and MEs, as well as CERT and CSIRT national authorities, can use the SL client to send their CTI data as STIX objects. Upon the delivery of a STIX object, SL firstly encrypts its content with the owner’s public key, and then store the resulting ciphertext into the IPFS network, which assigns to it a CID. Finally, SL creates a NFT on the Algorand network that contains the CID and its URL pointing to the IPFS network.

Sharing CTI data on SL

SMEs and MEs can use the SL tool of CyberKit4SME to securely share their CTI data. The first release of SL allows to insert a STIX object through a post-API, and to retrieve a STIX object through a get-API. The following screenshot shows how a user can insert a STIX object on SL. In this example the CTI data represents an indicator of compromise concerning a file hash of a variant of the Poison Ivy malware.

POST API to insert a STIX object in SL

POST API to insert a STIX object in SL

The following screenshot shows the result of the previous post-API request. The response body contains three fields:

  • the identifier that is the STIX object id, i.e. the name of the bundle;
  • the version that is the timestamp of when the STIX object is stored on the IPFS network;
  • the message that is the the transaction identifier of the corresponding NFT on the Algorand network.
Outcome of a POST API on SL

The SL response after inserting a STIX object via POST API

By using a blockchain explorer, such as Dappflow, it is possible to search for the transaction identifier and explore its details. In our example we copied and pasted the message field of the post-API response, and we then obtained the details of the associated NFT.

A NFT representing a STIX object stored on SL

The Algorand NFT representing the STIX object inserted on SL

The URL field of the NFT points to the CID stored on the IPFS network. By clicking on it, users are redirected on IPFS and can retrieve the associated STIX object. The following screenshot shows the CID on IPFS. Specifically, the CID comprises two JSON files:

  • the metadata.json that records the main details of a STIX object, e.g. its identifier and timestamp;
  • the object.json that records the encrypted STIX object.
The IPFS CID representing a STIX object

The CID of a STIX object stored on the IPFS network