Requirements for certified Infrachain NodesVersion: 0.4
REQUIREMENTS FOR
CERTIFIEDINFRACHAIN NODES
Notice
The present document can be downloaded from:
The present document may be made available in electronic versions and/or in print. In case of anydifference in contents between such versions and/or in print, the only prevailing document is thedocument available at the above mentioned URL.
The document may be subject to revision or change of status, without prior notification. Information about the latest valid revision of the document is available at the above mentioned URL.
If you find errors in the present document, please send your comments to:
Copyright Notification
No part may be reproduced or utilized in any form or by any means except as authorized by written permission of the Infrachain Initiative.
Key Words
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
The key word "CONDITIONAL" is to be interpreted as follows:
CONDITIONAL: The usage of an item is dependent on the usage of other items. It is therefore further qualified under which conditions the item is REQUIRED or RECOMMENDED.
References
[AMLD4]: The Directive (EU) 2015/849 of the European Parliament and of the Council of 20 May 2015
on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing and repealing Directive 2005/60/EC of the European Parliament and of the Council and Commission Directive 2006/70/EC
[eIDAS]:Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC.
[GDPR]:Regulation (EU) 2016/679 of the European Parliament and of the Council 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)
[ISO27001]: ISO/IEC 27001:2013 “Information technology -- Security techniques -- Information security management systems – Requirements” (ISO)
[ISO27002]: ISO/IEC 27002:2013 “Information technology -- Security techniques -- Code of practice for information security controls” (ISO)
[PSD2]:Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC
[RFC2119]: RFC 2119: “Key words for use in RFCs to Indicate Requirement Levels” (IETF)
[SOGIS]:Crypto Evaluation SchemeAgreed Cryptographic Mechanisms (SOG-IS, Senior Officials Group Information Systems Security):
Document history
Version / Date / Author / ModificationsContents
Notice
Copyright Notification
Key Words
References
Document history
1.Introduction
2.Scope
3.Definitions
4.General concepts
4.1. Compliance requirements
4.2. Management of the certified status
4.3. Supervision audits
4.4. Notification of incidents
4.5. Monitoring
5.Requirements
5.1. Financial capacity
5.2. Information security policies
5.3. Organization of information security
5.4. Human resources
5.5. Asset management
5.6. Access control
5.7. Cryptography
5.8. Physical and environmental security
5.9. Operations security
5.9.1. Operational procedures
5.9.2. Protection of the Hosts
5.9.3. Backup
5.9.4. Logging and monitoring
5.9.5. Control of operational software
5.9.6. Technical vulnerability management
5.10. Communications security
5.10.1. Security of network services
5.10.2. Service level agreement
5.10.3. Security of exchanged information
5.11. Incident management
5.12. Business continuity
5.13. Compliance
1.Introduction
The main objective of the Infrachain Foundations is to create a community-driven “node-independent“ permissioned node network where Blockchain applications can become operational and still profit from a consensus driven environment driven by the blockchain and be able to comply with current regulation.
The aim of Infrachain is it to be a cross-industry effort providing disintermediation services to all aspects of our economy (Fintech, Healthcare, Public services, Supply chain …).
A main pillar of Infrachain’s offering is an “on-top” governance layer to the commonly used DLTs aiming to bridge the gap between the technological trust attributes of DLT and the customer/end-users perception of trust.
The Infrachain Foundation governance papers are intended to bridge this trust gap and layout a commonly accepted governance for the Infrachain community.
This specific certification paper lays out the requirements a company must fulfil to become certified and to be able to operate hosts and services DLT-applications under the terms of Infrachain Foundation.
2.Scope
The present document establishes the minimum requirements for certifiedInfrachainHosts.
The certified status is given by the Infrachain Supervisory Body to specific InfrachainHosts which provide the highest level of trust and quality of services. To obtain the certifiedstatus for its Host(s), a Host operator SHALLdemonstrate compliance of these Hosts with the present requirements by mean of a certification from an independent Infrachain Conformity Assessment Body. The certified status is a mandatory prerequisitefor a Hostto be connected to other InfrachaincertifiedHosts.
The present document does not cover:
-the underlying blockchain protocol used in the Infrachain blockchain
-the software client application used to implement this blockchain protocol (Infrachain node)
-the smart-contracts run on the InfrachainHosts
-the data stored in the Infrachain blockchain
-any additional software, hardware, network or environment aiming at accessing external systems from the InfrachainHost.
In particular, compliance with the requirements laid out in the present document does not provide any guarantee with regard to:
-the correctness of the applications and smart contracts run on the Infrachain blockchain
-the accuracy and confidentiality of the data stored in the Infrachain blockchain
-the confidentiality of the data exchanged between the Host and external parties
3.Definitions
The following definitionsare used in this document:
-Host: an information system, consisting of software, hardware, hosting environment, business processes and staff, which is aconnection point of the Infrachain blockchain.
-Host operator: the entity responsible for ensuring that a Host performs correctly and reliably its functions as a connection point of the Infrachain blockchain.
-Infrachain node:a software component provided to Host operators by the InfrachainFoundationto implement their Host. The use of an official, unmodified Infrachain nodeis mandatory for each Host.
-Infrachain Supervisory Body (I-SB): the entity in charge of the supervision of the Hosts, including the management of their trust status, and their connection/disconnection to the Infrachain network.
-InfrachainAccreditation Body (I-AB): the entity in charge of accrediting I-CABs to assess and establish the compliance of a Host with the requirements laid out in this document.
-Infrachain Conformity Assessment Body (I-CAB):an independent entity accredited by the I-ABto assess and establish the compliance of a Host with the requirements laid out in this document.
-Last Man Standing (LMS) node:a special type of certified Infrachainnode which offers a higher level of services through a dedicated SLA.
As an illustration of these definitions, the following diagram shows a sample Infrachain infrastructure with 2 blockchain instances, each one made of 5 nodes and used by a single DLT application / smart contract. These 10 nodes are hosted on 5 hosts and therefore managed by 5 host operators.
The following diagram illustrates the relationship between the various actors involved in the certification process:
4.General concepts
4.1.Compliance requirements
In the present document, the management of information security of the Hosts is based on the principles from [ISO27001]. Relevant controls were selected from [ISO27002], and additional specific requirements, including stipulations for implementation, were added to meet the objectives of the Infrachainproject.
An ISO27001 certification is not required to obtain the certified status. Access to the [ISO27001] and [ISO27002] standards MAY help to implement the requirements laid out in the present document, but is not required.
4.2.Management of the certified status
The I-SB supervises all InfrachainHosts and manages their certified status according to the rules described in the Infrachain Governance document.
4.3.Supervision audits
Host operators of certifiedHosts SHALL be audited at their own expense at least every 12 months by an I-CAB to confirm that their Host(s) fulfil the requirements laid down in this document. The I-CAB SHALL submit the resulting conformity assessment report simultaneously to the Host operator and to the I-SB.
Without prejudice to the previous paragraph, the I-SB MAY, at any time, audit or request an I-CAB to perform a conformity assessment of a Host, at the expense of the Host operator, to confirm that the Host fulfils the requirements laid down in this document. Where personal data protection rules appear to have been breached, the I-SB SHALL inform the CNPD of the results of its audits. Where it determines that it is in the public interest, the I-SB MAY inform the public of the results of this audit.
Where the I-SB requires the Host operator to remedy any failure to fulfil requirements from this document for a Host it operates, and where that Host operator does not act accordingly, the I-SB MAY withdraw the certified status of the Host and disconnect it from the Infrachain network.
4.4.Notification of incidents
Host operators SHALL, without undue delay but in any event within 24 hours after having become aware of it, notify the I-SB of any security incident that has a significant impact on the operated Host(s) and on the Infrachain as a whole. The I-SB SHALL inform the natural or legal persons which rely on the Infrachain for services. Where it determines that the security incident is in the public interest, the I-SB MAY inform the public.
4.5.Monitoring
The I-SB SHALL implement technical means to monitor all certifiedHosts, so that abnormal behaviour of a Host is promptly detected and reported to the I-SB. Host operators SHALL facilitate the implementation and support of this monitoring system with regard to the Hosts they operate.
5.Requirements
5.1.Financial capacity
The Host operator SHALL demonstrate that it possesses the economic and financial capacity to operate certifiedHost(s) according to the requirement laid out in the present document.For instance, the Host operator MAY provide an extract from its national Business Register, balance sheets and profit and loss accounts for the last 3 fiscal years, financial reports issued by an independent auditor or a national supervisory authority, etc.
The Host operator SHALL also provide a declaration on honour, signed and dated by an authorised representative, stating that the Host operator is not in a situation incompatible with the operationof InfrachainHosts. Such situations include, but are not limited to:
-If it is bankrupt, subject to insolvency or winding up procedures, having its assets administered by a liquidator or by a court, or having its business activities suspended
-if it isin breach of its obligations relating to the payment of taxes or social security contributions in accordance with the law of the country in which it is established
-if it has been established by a final judgement or a final administrative decision that the person is guilty of grave professional misconduct, fraud, corruption, other criminal offences, and any other irregularity which have an impact on its professional credibility
-any analogous situation arising from a similar procedure provided for under national legislation or regulations.
The I-SB MAY request at any time from the Host operator documentary evidence to support the statements listed in the declaration on honour.
5.2.Information security policies
A specific InfrachainHost information security policy SHALL be defined by the Hostoperator, approved by its management, and communicated to employees and relevant parties. This InfrachainHostinformation security policy SHOULDdefine the security objectives and principles to guide all activities relating toinformation securityfor the operated Host(s).
At a lower level, the InfrachainHostinformation security policy SHOULD be supported by topic-specific policies, which further mandate the implementation of information security controls to meet the requirements laid out in the present document.
Each policy SHOULD be reviewed yearly by the Host Operator, and each revised policy SHOULDbe approved by the Host Operator’s management.
5.3.Organization of information security
All information security responsibilities related to Host operations SHALLbe defined and allocated in accordance with the information security policies. Responsibilities for the protection of individual Hostassets and for carrying out specific information security processes SHOULD be identified and documented.
Distribution of roles and access rights SHOULD enforce, to the best extent possible, segregation of duties, so as to avoid that no single person can access, modify or use the Hostwithout authorizationor detection. Additionally, local monitoring of activities on the Hostand audit trails SHOULD be put in place by the Host Operator.
The Host Operator SHOULDmaintain appropriate contact with the I-SB. In particular, the Host Operator SHALL notify the I-SB of any identified or suspected relevant information security incident.
Contactswith relevant regulatory bodies are also RECOMMENDED, since they help to anticipate and prepare for upcoming changes in laws orregulations, which have to be implemented by the Host operator. Examples of such regulatory bodies include the CSSF, the CNPD and the ILNAS.
5.4.Human resources
The Host Operator SHOULD ensure that its employees and contractors, prior to being granted access to the operated Host,are properly briefed and understand their responsibilities regarding confidentiality, data protection, ethics, and that they agree to the terms and conditions concerning information security in the context of the Infrachain initiative.
The Host Operator SHOULD ensure that its employees and contractors are suitablefor the roles for which they are considered, and in particular that they possess the appropriate skills and qualifications.These skills and qualifications SHOULD be maintained through regular trainings.
The Host Operator SHOULD ensure that its employees and, where relevant, contractors are aware of the present document, as well as any change of revision.
The Host Operator SHOULD ensure that responsibilities contained within any confidentiality agreement and the terms and conditions of employment with regard to Infrachain remain valid after termination or change of employment.
5.5.Asset management
The Host Operator SHOULD identify assets involved in the operation of the Host, assess their importance and document theircreation, processing, storage, transmission, maintenance, deletionand destruction in dedicated or existing inventories as appropriate.
The asset inventory SHOULD be accurate, up to date, consistent, and aligned with other inventories.For each of the identified assets, ownership of the asset and associated responsibilities SHOULD be assigned.
Routine tasks such as maintenance may be delegated, but theresponsibility remains with the owner.
5.6.Access control
An access control policy(covering both logical and physical access to the assets)SHALL be defined, documented and enforced by the Host Operator, so as to minimize the opportunity for unauthorized access to the Host.Logical access to the Host assets SHALL be controlled by a strong authentication mechanism based on robust cryptographic solutions. In case passwords are part of this authentication, an adequate password policy SHALL be defined and enforced.
When defining access rights to assets, the Host OperatorSHOULD follow the principle of least authority, and to the best extent possible, segregation of access control roles. The allocation of privileged access rights (such as Host administrator roles, access to cryptographic material, etc.) SHALL be restricted and strictly controlled by the Host Operator.
Formal processes for user registration/de-registration and access provisioning SHOULD be implemented. Access rights SHOULD be periodically reviewed by the respective owners of the information systems or services. The access rights of all employees and external party SHOULD be removed upon termination of their employment, contract or agreement, or adjusted upon change.
In case the Host Operator authorizes remote access to the operated Host (such as for maintenance purposes), a policy and adequate supporting security measures SHALL be implemented to protect the operated Host. A RECOMMENDED security measure for remote access to the Host is the usage of a Virtual Private Network (VPN) with a 2-factor authentication supported by a hardware cryptographic device (such as a smartcard).
Access and usage of the assets SHOULD be monitored, and the resulting logs SHOULD be regularly reviewed.
5.7.Cryptography
A policy on the use, protection and lifetime of cryptographic keys used by the HostSHALL be developed and implementedthrough their whole lifecycle.The policy SHOULD include requirements for managing cryptographic keys though their whole lifecycle including generating, storing, backing up, retrieving, distributing, retiring, changing and destroying keys.
All cryptographic keys SHOULD be protected against modification and loss. In addition, secret and private keys need protection against unauthorized use as well as disclosure. Equipment used to generate, store and archive keys SHOULD be physically protected. Key management related activities SHOULD be monitored.
The policy on the management of cryptographic keys, including the choice of algorithms, key lengths and usage practices,SHOULD follow the recommendations of [SOGIS].
5.8.Physical and environmental security
To prevent unauthorized physical access, damage and interference to the Host, security perimeters SHALL be defined and used.Secure areas SHALL be protected by appropriate entry controls to ensure that only authorized personnel are allowed access.Access to secure areas SHOULD be monitored.
Examples of RECOMMENDED physical security controls include:
-a physical barrier which defends the boundary of the area hosting the Host(s), such as walls and fences protecting the entrance of a datacentre ;
-an intrusion detection systems to enhance the level of security offered by the physical barrier, such as an alarm system with mechanical sensors ;
-electronic, mechanical or electro-mechanical means to control access to the secure areas and to the assets, such as badge-controlled doors or key-locked racks ;
-security personnelto control access and deter potential intruders ;
-closed circuit television (CCTV) used by security personnel in order to verify incidents and alarms;
Host equipment SHOULD be sited and protected to reduce the risks from environmental threats and hazards, natural disasters, malicious attack or accidents.Host equipment SHOULD be protected from power failures and other disruptions caused by failures in supporting utilities.
Host equipment SHOULD be correctly maintained to ensure its continued availability and integrity.