Tech Spotlight:
An interview with a Data Expert on Data Privacy & Security

Finworks is a leader in data management,  particularly in financial services. Today, Marc Hoogstad, Head of Product Management and Gergana Tabakova, Head of Product Architecture, will discuss how to approach data security and privacy from a technical perspective. 

Gergana: Technically, security is not something which can be seen. It must be built inside the architecture on a lower level. 
It's not something that can be added on top. It is a process which needs to be followed every day. So it's not only that it is part of the architecture built in the application, but it is a day-to-day process to be followed in order to ensure the security of the data inside the data management system.

When we think about data security, there are usually 3 aspects.

The first aspect is confidentiality – For example, if we have to approach a potential customer or we need to prepare for a demo, this will be the first thing we will ask. What is the level of  confidentiality of the data? Less security is needed for public open-source data and we don't need to put in the security features required for  market-critical data. 

Depending on the data confidentiality, we will design what data access measures will be best for this specific customer.  Ideally, a data management system should be flexible. It should offer different access methods. If the data are public, it shouldn't add any complexity on top. If the data are sensitive, it must ensure that they are protected.  

Then, about the sensitive data, again, there could be data objects which are accessible to a group of people or a certain role. But as well, within one data object, we could have data elements. This could be columns or records which are highly sensitive. It could be that the lower user group has access to some lists, but they shouldn't have to have access to certain columns. For example, they should not have access to  employee salary, but they should be able to see a list of employees.  

 We are talking about two security models there. One is a row security model, where usually, a row has permissions on an object. Then, even columns are objects. But then we can talk about more fine-grained security where inside the same data object or table, we can have data with different confidentiality. So, the access is not only an object level but a row-by-row level. So, for every record, whether it should be returned to the user or not it depends on the confidentiality flag inside this record. Ideally, a data management system should support all these flavours.  

 Then what is next? We would then ask potential customers about their data availability requirement. It's the second pillar of the security. Availability is important because you can have data but if you can't access them, for example if  you need to access them 24/7, then your data management system is not secure.  

 Based on our client's requirements, we can design a data availability architecture. There is no need to take high availability measures if the client is able to work with data that is up to three days old if the system is down. There is a cost implication for having very highly available data.  

If they don't need it, why should they pay for it?

But if they say that their business will stop or it is critical to the business, their business will be badly impacted if their system is down, then we need to take  more measures to ensure data availability. Loss of data might simply be data centre hardware issues. Or the concern might be hacker attacks against the system. Having availability means the system can be up and running on another node or another availability zone.  

 The third aspect is the data integrity. Again, this depends on what the system is, what their business impact is, if the data are not correct. For example, if there is an attack and part of their data is deleted or part of their data altered, it could be that a malicious actor made their data wrong.  

 Then, we need to take additional measures. Data integrity requires high protection for how the data are entered and how data are processed inside the data management system so that malicious actors can't really tamper with data.  

We can go through several real-world examples of the impact of data security and privacy on data management. For example, if the data management platform collects financial transactions and these are linked to the market, then confidentiality should be higher in this case.  

 Another example is if I'm collecting some financial information and I rely on this data to make business decisions, but suddenly these data are wrong, somehow replaced on the way to the data management system, and I make wrong decisions, then my data integrity requirements will be higher. 

Moreover, my system must always be up because without it, who knows what can happen? So this should be a requirement for us designing the availability of the system.

Furthermore, a Data Management system is software with a set of components, but they can be configured differently for different customers. So, there is no one size fits all, and it could vary with the possible security. But again, the customer must pay for the underlying cloud infrastructure to ensure all this, and it might not be needed. A tailored solution could be optimal in terms of value and cost.

Marc: From our perspective, we have data security by design, and all three pillars are important.  Also, having access and permissions, availability and integrity, and having the highest levels of all of those, obviously, there's a trade-off in cost. We listen to our customers to understand what are their priorities and what they need for a particular data management platform. And then and then we develop those in as needed.

Can you talk a little bit about how we share data securely as well? I think we've been mostly talking about data in a box, in a secure system, but obviously, data is to be shared and transmitted onwards. Can you talk a little bit about that?

Gergana: By design all data in all data management platforms should be encrypted. Then this encryption should be both at rest where the data are stored and in transit.

 When we share the data, they simply share them via https channel because it is encrypted and it is secured. 

Depending on the requirements, what could be done to increase security on top of the receiving channel or descending channel? If we are the recipients, we could implement certificate authentication so that only the sender or receiver with the right credentials can complete the data  handshake.

If the data  requirements are even higher and it's very important that these data are not obtained by any other third party.  Then, the data could be encrypted before sending.  So even if someone manages to take over the channel to get this file, they would not be able to read this data because only the recipient can decrypt the data. We have all these possible solutions for different use cases for different customers. 

Marc: And anything else you want to mention about secure data storage and backup? 

Gergana:  About secure data storage. There are two aspects encryption and recovery. Stored data should be encrypted and it should be ideally encrypted with a customer manage key, and this key should be securely stored, and the access to the key should be limited from an access point of view. 

Then, the solution should be built with the point of view that the data, whatever happens to the data, this secure storage should be recoverable. The aim should be for zero data loss, to recover the latest moment, but also to recover it as quickly as possible so that the system downtime is minimised as much as possible. 

Marc: How does the prevention of cyber-attacks or data breaches fit in? 

Gergana: This is where the day-to-day process comes in. 

Marc: You might mitigate risks. But then you always have to be continually vigilant.

Gergana: There is no product which doesn't rely on 3rd party software, even if it is totally serverless. These serverless components they have inside some operating systems. And everything has vulnerabilities. Sometimes, one critical vulnerability is publicly announced. It could be used in the next couple of weeks. Whoever doesn't patch are open to outside parties who try to take advantage of the system which is not patched and attack it somehow. So vulnerability management should really be a daily process, which means that there should be a daily check for vulnerabilities. If there is something which is new with critical risk, it should be immediately be resolved as soon as possible. 

In addition to the vulnerabilities, there are other tools which come as well with the cloud-native. On top of static analysis of the underlying infrastructure, there are some ports open or vulnerable components.  

They also scan for unusual behaviour, and they raise alerts if there is anything suspicious. Again, it's a daily process, and this alert should be followed up on a daily basis on live production.

Marc: I think we have a really good idea of how privacy and security are built into the design, into the daily activities and into any data sharing. So now, looking forward, could you describe any future trends for 2024 for security and privacy?

Gergana:  Looking into my crystal ball, tools that help with access are needed, to help improve row-by-row-based access control. It's something which is not built within most of the big data components. It should be provided on top of the data management system, and probably, the business requirements could always surprise the designers. There could also be some new use cases, so I see that this is a direction for further improvement in general.

Marc: OK, a tool or a new method of providing access and role model, role-based permissions.

Gergana: Another area probably for further development is to develop more rules to detect suspicious actions on a day-to-day basis.

There is a minimum level which comes with the cloud-native tools. There are some open-source tools as well,  but they don't cover yet everything that might happen. So their custom checks on the day-to-day operations is something which they're looking for next year.

Marc: Obviously, you need someone looking at those exceptions and acting on them so that they're addressed as soon as possible.  And there's always an operational part of that.

I think we really covered a lot of aspects about data security and privacy. Thank you very much for answering so fully, it was a great insight into this topic.