Blog: Demonstrating Ransomware resistance SaaS applications raises question marks

Demonstrability is important partly because of the scale of the threat, but also because regulators demand it. And those demands will grow: new regulations, such as the NIS2, will demand even more attention to the demonstrable management of risks by suppliers and supply chain partners. This blog therefore focuses on this issue and lessons found and considerations you can take into account as a business user of SAAS solutions.

Immutable storage and demonstrability
When it comes to resilience against ransomware, storing the backup in so-called "Immutable Storage" plays a crucial role. Making the backup unusable by changing, encrypting or deleting it is then prevented. 

But how can you be sure that the backup of your SaaS application is stored ''immutable''? And how can you prove this to your regulators?  A working group from CIOPN, consisting of Paul Samwel (CISO, ONVZ), Frans Voogd (Security Officer, Heijmans), Marcel van Essen (Risk & Security Coördinator, Havenbedrijf Amsterdam), Ton Sundemeijer (Information Security Officer, TBI), has been looking into this issue in recent months.

Business user needs in 6 questions
In theory, it seemed simple after all: If we clearly formulate what we expect from the SaaS suppliers and phrase these questions in a way that the SaaS suppliers can do something with, then we can more easily and effectively receive the same answers from our suppliers. In our enthusiasm, we threw ourselves right into the content. In doing so, we arrived at content messages such as:

As a customer, can I work with my SaaS provider to restore services within a reasonable time after a successful ransomware attack at my Cloud provider?

1. Do you back up application, infrastructure and data?
2. Is the backup "Immutable"?
3. What is the retention period of the backup?
4. How much time is required for recovery until a working environment is delivered?
5. Is periodic readability checking done with periodicity < retention period?
6. Does periodic testing of functional recovery of SaaS service take place (based on backup of application, infrastructure and data)?

Please indicate here:

1. What does the SaaS provider do in this context?
2. What are the tasks of the customer (User Entity controls) in this context?
3. To what extent is compliance part of existing TPM statements (ISAE, SOC2)?

 Obstacles
So how to take this result further in practice? In doing so, we coordinated with colleagues from EY, AFAS, Exact, Chrunchr and NOREA. This revealed that both Exact and Crunchr did address their ransomware resilience in their ISAE or SOC2 statements. However, the way in which differed considerably. Exact takes a risk-oriented approach in which ransomware is recognised as a risk and must therefore also be reflected in the measures (but not explicitly named), while Crunchr does explicitly name the immutability of the storage in its statement.

This is a consequence of the fact that such statements place the standards to be used with the supplier. In addition, vendors indicated that the ISAE and SOC2 tool is also not really suitable for a "rule-based" approach where the rules are prescribed. We therefore found that the ISAE statement tool cannot easily be used to initiate this uniformity in the market.

Can upcoming regulations help?
As mentioned, the NIS2, among others, will bring this problem further to the fore. But it may also start to force a solution in time. After all, almost every company will face this challenge and will therefore have to find a solution. That solution will not fall from the sky.

As CIO Platform Nederland, we might as well keep looking for a pragmatic and workable solution. After all, nobody is waiting for impossible demands from regulators. But if we do nothing, this does threaten to happen.

The NOREA Report Initiative on the reporting standard accountability IT controls (NOREA | Consultation Reporting Standard Accountability IT Controls (NOREA Reporting Initiative) may also be a possible starting point. However, this one is still in consultation phase. And the same applies to that: Standard Cyber-1-1f reads, "The reporting organisation should report on the backup strategy and activities to ensure that backups are conducted, secured, maintained and tested periodically." Does this provide sufficient assurance about the Ransomware resistance of data?

Lessons
Through the process, we have learned a lot of lessons. Perhaps with additional input from the participants of the CIO Platform Netherlands, we can take another step forward. Below are three insights found from the process of the past few months:

Lesson 1:
Large SaaS vendors are themselves engaged in this issue. After all, it is their "licence to operate". Should a SaaS vendor be hit by a Ransomware attack, it will have serious and perhaps disastrous consequences for their livelihood. The concern that SaaS providers are handling this carelessly therefore seems unfounded. However: demonstrability thus remains a challenge. Especially in the context of DORA where you, as a customer, are explicitly responsible for validating the security quality of your (sub)contractors.

Lesson 2:
SaaS vendors are not waiting for additional questions (lists) from their customers. The (big) vendors receive hundreds of such lists, too many to pay serious attention to them and be able to answer them with sufficient quality. For that reason, there is surely a certain aversion to additional questions from their customers. As a result, they don't get to the important issues like securing our data. They prefer to get one uniform questionnaire from all their customers so that they can spend enough time on it and publish the answers on their website. Furthermore, the amount of different lists is also a recognisable problem for many business users.

Lesson 3:
The current ISAE3402 type 2 statements provide not enough guidance for enforcing demonstrable ransomware resilience. After all, the ISAE3402 process places the determination of the scope and nature of the measures on the provider. A requirement on a particular type of measure (such as Immutable storage for backup) for one of the risks does not fit into that process. Adding this demand is therefore not an addition on content but an adjustment of the process from risk-based to rule-based. Therefore, the most common TPM (ISAE3402) does not provide sufficient leverage. The SOC2, where the scope of operational IT controls is not entirely free but partly based on the Trust Services Criteria, could be useful. However, the number of SOC2 statements in the Netherlands still lags behind the number of companies issuing an ISAE3402 statement. In addition, availability in SOC2 is not (yet) a mandatory component and the depth of the control in question is too limited to guarantee immutable storage ("The integrity and completeness of backup information is tested on at least an annual basis").

Conclusion: work in progress!
In brief, it is a complex but important issue that cannot be solved unilaterally. The risk of vulnerabilities and limited monitoring will therefore remain for the time being. It requires us to stay alert from the business user's perspective and keep looking for better answers. 

Do you know how to contribute to taking this issue further and making the Netherlands safer? How do you see the future and development of supervision within cyber? Let us know!

Paul Samwel (CISO, ONVZ)
Frans Voogd (Security Officer, Heijmans),
Marcel van Essen (Risk & Security Coördinator, Havenbedrijf Amsterdam),
Ton Sundemeijer (Information Security Officer, TBI)

For comments and/or questions send a message to Idsard