|
 |
|
|
|
itrust Abstractions Lab released the Beta version of C5-DEC on GitHub. This release includes many new functionalities, mainly to assist with Common Criteria evaluations and efficient creation of technical documentation throughout the Secure Software Development Lift Cycle (SSDLC).
We will be happy to receive your feedback at info@abstractionslab.lu
Interview with Smart Cities, translation by itrust consulting.
The NIS2 Directive, Europe's cybersecurity legislation, introduces legal measures designed to strengthen the protection of networks and information in a Europe faced with increasingly sophisticated threats and malicious acts. It will come into force in Autumn, at which time public and private entities actors will be requested to proof their credentials to the regulator, responsible for sanctioning any related breaches. Carlo Harpes, founder and managing director of itrust consulting, an expert in cybersecurity since 2007, sheds light on the challenges of compliance, and presents the tools specially developed by the
company to meet those challenges.
The European NIS2 directive will come into force this autumn. What do we need to know about it?
Its noble aim is to prepare the public sector and certain new private sectors for the challenge of cybersecurity. It must be transposed by October 15, 2024, by which time all European entities concerned must be compliant. From that date onwards, they will be expected to manage cybersecurity according to "applicable international standards", based on an "assessment of the probability and consequences" of a series of risk scenarios. It should be noted that they will be obliged to justify themselves to a national regulator, namely the Institut luxembourgeois de Régulation (ILR) or the CSSF for the financial sector.
This second draft of the directive is worrying because it announces penalties similar to those for non-compliance with the GDPR and gives the ILR the right to impose measures including the removal of the top management. What the penalties will really punish is ignorance. Thus, top management is allowed to knowingly refuse to invest in important security measures and choose to run a risk, provided that such decisions are documented and justified. But it will not be entitled to ignore a request for information, or a binding instruction the regulator.
How do your customers react to these requirements?
They're fed up with regulation and compliance. But there's no point complaining: it's all part of the zeitgeist. When we carry out GDPR compliance projects, we observe that about a third of the work is linked to documentation and may indeed seem tedious. But another third is devoted to training and empowering staff, a very productive step that many entities neglect. The final third of the effort consists of better implementing security measures. These include e.g.: commissioning an independent expert to play the role of hacker and test the security of a system and the data it contains – a practice long approved and applied in the financial sector, but rare in others; auditing access annually – an administrative task, but justified by the number of errors identified, or the business continuity plan exercise. When it comes to cybersecurity, everyone is responsible, especially in the public sector, where employees take an oath. However, standards stipulate that any breach of good security practices can be attributed to an individual. This means that security rules, policies and procedures must be clearly documented and explained to employees. Of course, the behaviour of agents and employees is not everything. Once good organizational practices have been identified, it's time to install threat and vulnerability monitoring solutions, technologies that are making increasing use of artificial intelligence, just as attackers are already making extensive use of it to find ways of infiltrating their targets' systems.
Could you describe OpenTRICK, the solution you created to meet the requirements of NIS2 and ILR?
OpenTRICK (Tool for Risk management of an ISMS based on a Central Knowledge base) is a risk analysis tool that we extended as part of CyFORT (Cloud Cybersecurity Fortress of Open Resources and Tools for Resilience), a research project aimed at addressing security issues, particularly in the cloud. As the name suggests, it's an open-source solution that anyone can use and contribute to, as long as they publish any changes they make.
Since the entry into force of the first NIS directive, ILR has been encouraging stakeholders to assess risk scenarios that it has predefined itself, and requires the results obtained by filling in multiple parameters for each combination of assets and risks to be entered manually on its website, or imported into a publicly known, but rather complex, json format, supported by MONARC.As MONARC, which is also open source, does not have an API (Application Programming Interface) enabling information to be easily imported, we developed Trick2MonarcApi, an open-source interface facilitating the migration of risk information into the data format required by the regulator.Then, our OpenTRICK tool used TRICK2Monarch API to put customer data into the json format. The advantage of this solution is that the customer continues to name assets and risks in his internal well known way and uses correspondence grids for export data to the ILR. OpenTRICK also has the advantage of allowing knowledge to be imported and exported in Excel spreadsheet format, displaying graphs and adding an economic estimate, such as the average annualized losses and cost parameters of measures to be considered, which is not foreseen in the ILR tool SERIMA.
Nevertheless, OpenTRICK, like MONARC and SERIMA, provides an overview of threats, but is no substitute for in-depth knowledge of a specific process or system, or for unravelling the individual vulnerabilities of that system. The most effective approach for this is collaboration, among internal business experts and external risk experts.
As one of these experts, what advice would you give your customers in a context where cyberthreats are increasingly present?
Be proactive and show that you have succeeded in implementing a reasonable level of security before an attack occurs and before the regulator imposes measures. The latter is rarely inclined to compromise after an incident. That's why we recommend implementing "quick wins" before regulators demand them.
