This document shows the security level of TruBudget via FAQ. Do not hesitate to ask a security question, so the TruBudget team can answer it and expand the FAQ - just open an issue.
Multichain is a high-performance private/permissioned blockchain technology which allows high-throughput on standard hardware. Additionally, it works well in cases of network partitions.
TruBudget was developed in a classical layered 3-tier architecture model. The TruBudget API uses the Hexagonal Architecture Standard. Communication uses HTTP over JSON API Standards and the Frontend uses the Atomic Design Principles.
Open-Sourcing allows multiple parties to use TruBudget without procuring the software (which is a timely exercise). Open-Source is at no costs. From a security perspective open-sourcing is making development more transparent and required automatically a higher level of quality. TruBudget enforces modern Security Standards and all necessary secrets have to be set at Runtime.
In general, all processes important to more than 1 stakeholder/business partner may be carried out on TruBudget.
- Request to sign a contract by stakeholder A – Upload of signed contract by stakeholder B
- Request to approve a report by A – Upload of approved report by B
- Request to give no-objection to tender documents by A– Documented no-objection by B
- Payment documented by A – Confirmation of receipt by B.
- Information by A – Validation by B.
Internal processes are not supposed to be part of TruBudget as it is a multi-stake-holder tool. TruBudget is very flexible in regard to the applied processes. In each use case the stakeholders will decide on relevant processes to be put on TruBudget in order to facilitate their joint business.
Data confidentiality is guaranteed on API level. Users need to be authenticated and authorized in order to request data from the API based on a role-base access model. Data at rest (in the blockchain) is visible to persons with access to production server.
No. Transactions are signed with the user’s private key which is related to an organizational wide secret. Transactions can only be signed on nodes of the user’s organization. Multiple signing is possible, but not implemented (e.g. 4 eyes principle). However, within an organization writing rights on TruBudget may be organized according to internal requirements (e.g. internal approvals before entering data).
Given that the proper functioning of TruBudget is linked to existing tools and their interfaces TruBudget exposes a secured API. Access to the API is secured with JWT Token (1 day validity). The tokens can be obtained using Basic Auth through a Login endpoint.
- no double entries of data
- data are generated while working on processes
- all stakeholders use same data, no need to compare data
- automatic exchange of data will replace cumbersome reports
- validated data will improve quality of data-based planning and reporting
- access to high quality data at any time in real-time
- user interface easy to use, limited training needs for users
- web-based application, no need for hardware investments
- no need to change current IT systems (as TruBudget is linked via API)
- API linkage to stakeholders’ IT systems allows use through own ERP instead of TruBudget user interface
On node-level communication needs to be ensured through VPN or with the use of Multichain Enterprise. On API level communication is encrypted using TLS.
Yes, every change is stored in an immutable transaction and can’t be deleted. The transactions can be accessed through TruBudget’s history functionality or by using the low-level Multichain API “getBlock”.
The requirements can be found in the installation guide.
There is no realistic limitation here.
There are two ways Nodes can join the TruBudget network:
- A node of a new organization wants to join
- A node of an existing organization wants to join
In both cases a certain number of organizations in the network has to approve the new node. The difference is that a new organization needs 51% of all organizations in the network and a new node of an existing organization only needs one approval. More about how to connect a new node to an existing network can be found in the documentation.
First of all, internal systems can’t be accessed through other TruBudget instances/ nodes. Data can be accessed directly through the multichain-cli available on TruBudget’s node instance or through TruBudget’s API. Direct access to a node should be restricted by the organization itself. Access using the routes of TruBudget’s API is protected by user authorization through JSON Web Tokens. There are 3 different secrets which an organization must provide to setup a new node:
RPC_PASSWORD: Additionally, an API can only connect to a node in the network knowing the right
RPC_PASSWORDwhich is set by the first node (master node) of the blockchain network.
ORGANIZATION_VAULT_SECRET: Every node belongs to an organization which has its own stream on the multichain. The data in this stream can only be accessed through the node which belongs to this organization using the
ORGANIZATION_VAULT_SECRET. This secret is shared between all nodes of one organization.
ROOT_SECRET: The root secret is the password for the root user. If you start with an empty block-chain, the root user is needed e.g. to add other users or approve new nodes.
TruBudget scales horizontally and is therefore easily scalable by adding multiple instances.
TruBudget uses in-memory caching strategies in order to ensure low latency for read operations.
The longer chain wins: Transactions in the shorter branch re-enter the memory pool of nodes, which leaves them in the regular situation of waiting for confirmation, but being visible to all nodes. The only exception is if some of those transactions conflict with transactions which are already confirmed on the longer branch, or already in the memory pool, in which case they are discarded.
In private/permission-less networks there is no need for Proof-of-Work algorithms. Round robin allows high throughput with acceptable security. The consensus algorithm can be configured if required.
The bottleneck of TruBudget is Multichain. The number of transactions per second are depending on the hardware. On standard hardware TruBudget can allow 2000 transactions per second.
Data-volume stored on the chain is very small. On system with large disks, TruBudget can run for a very long time. As example: the provisioning of TruBudget available in the github repository of TruBudget is generating test data which currently includes 7 users and 4 projects on one node. After provisioning a fresh installed TruBudget chain is completed the chain size increases by 2MB. In case that disk usage exceeds disk capacity TruBudget could fulfil time-based partitioning where old data is archived and current/new data is transferred to a new TruBudget instance.
Communication between Frontend and API is encrypted using TLS and restricted to authenticated and authorized users. The API validates requests and enforces role-base-access rights for every resource. Access from the API to the chain is encrypted using TLS and secured using a shared secret. Communication between blockchain nodes is done using TCP and has to be secured using VPN.
TruBudget is designed to be as generic as possible which means that no restrictions shall be forced where it isn’t needed. However, since data can’t be removed from the blockchain, users should be drawn attention to not enter personal data which is stored on-chain. That regards only the choice of user names, name of projects, sub-projects and workflow-items. Currently emails typed into a user’s profile and documents are not saved on-chain and may therefore contain personal data if required and permitted according to respective regulations. Emails are saved in a local database and not replicated through the blockchain therefor they can be deleted if required. For saving documents multichain’s off-chain-storage is used which means documents are shared but can technically be deleted.
TruBudget versions are backwards compatible, which means different versions of TruBudget can run in the same network. There are strategies in place for breaking versions which will automatically enforce nodes with older versions to update to a newer version.
Access to production infrastructure needs to be secured by the operation team. The security relevant configurations like consensus requirements can’t be changed after the first block was mined.
TruBudget has been penetration tested using the OWASP Zed Attack Proxy (ZAP), which is a very popular open-source penetration testing tool maintained under the umbrella of the Open Web Application Security Project (OWASP). Our system underwent analysis and attacks from simulated malicious attackers. The tool acted as a “man-in-the-middle proxy” between the browser and the web application and tested if the application is vulnerable to attacks such as SQL Injection, Cross-Site Scripting, Path Traversal, Format String errors and many others. The results of the tests helped us discover vulnerabilities and allowed us to improve the security of the applicaiton and strengthen our defenses against such attacks, by implementing different security measures, checks and validations.