Some things are similar and quite different, not because of the application security itself but because of the ecosystem.
Telcos and financial markets- High-regulated markets by default. They are more risk averse. Everything is different. And a lot of the applications in the ecosystem of those companies, you have home banking, mobile applications, but there’s a lot of internal applications. Often, they rely on a lot of the holistic security you put on them, meaning network security, etc. So, to a certain point, they may not be that exposed. I’m excluding the mobile applications for banking.
And when you go to the SaaS, it’s quite the opposite. You are developing applications that you want to put either as an API or with the user interface; you want to put it out there, and you want it to be in the cloud, and you want it to be open to everyone.
So, in terms of threats, you are much more exposed to a certain point. While in the telco and financial, you may not be that exposed, but at the same time, you are in a sector that is much more a target because that’s where money is, mainly in the financial sector. So you have those threat landscapes that are different.
Then, when it comes to dealing with application security, there’s also the technology that you have. A lot of telcos and financials have more legacy systems. Of course, in the last few years, many have been operating more in more recent technologies, but they have more legacy technologies, and it’s working well. This is working. I prefer not to change it.
At the same time, the development process is also changing, but it is much more waterfall. Every change needed to update security patches, etc., was harder.
In SaaS, it’s different. If you fail fast, you also correct quickly. You use more recent technologies, and often, you can have very fast development timelines to solve the issues right. The concern I see, and this is a bit of criticism between two different development approaches, is in the waterfall.
Sometimes, you can put all the security or a lot of security requirements in the beginning and make sure they are implemented right in a perfect world in agile; a lot of teams develop MVP (Minimum viable product).
And when that product is working, we put it into production, start selling it, and now we need to go to another one. And we didn’t put all the security we required for the MVP because it was an MVP. You don’t invest a lot in security in MVP and try to save time on security in MVP.
And it’s a paradox because you know it’s much better if you do it initially. But if you’re doing an MVP, you want something working. So you’re not going to spend a lot of time in security. But you should.
And then, when it comes to production, it’s done. I’m selling this to customers. I don’t want to make a lot of changes now, and I need to do other MVPs. So, it’s a question of bandwidth that all companies face.
So that is one of the challenges that we have. It’s not regarding only culture. What lies behind the typical culture of software as a service? Of course, more mature companies like software as a service company have solved this problem.
But if you are initially talking about startups, it is what it is. And it’s always from a security perspective to try to push security in those MVPs. So, it’s different. Each company is different. It depends on how exposed you are, and what implications you have that are external or internal. But there are still differences.
I think SaaS is all about speed; you have hit the nail on the head, whereas in regulated environments like large enterprises, telecoms, and financial services, it is about being risk averse and having regulatory frameworks driving your entire protocol and mandate. And right now, in this group company that we are working out, there’s a lot of legacy and disparate systems that we probably have to deal with. which presents its own challenges as well.
There are always some issues… actually, you don’t have a lot of legacy systems. We are quite a recent company, to be honest, but it’s a different ecosystem, right? It’s a more complex ecosystem. We have a lot of on-prem stuff, and that brings back everything. It has pros and cons. But we also rely on some cloud providers and software as service providers. In that case, some of the responsibility is not on our side; it is on our provider’s side, but we need to make sure that we put some controls over them to make sure that they don’t fall into those issues that sometimes SaaS companies face.
And I think what is also happening is all the three things that you mentioned in a new age SaaS company that’s coming under one, like, for example, I mean here you have new age FinTech SaaS companies that are aggregating different kinds of services and pieces and open that is in India, there is this concept of open banking API. Then, there is this OCN (Open Credit Network) where you can quickly disburse loans for new-to-credit systems based on data and profiling. So, there is speed and aggregation of different technologies, which will have disparate systems, not necessarily legacy but new-age systems combining them and working in a FinTech or telecom market. So, you will have a mix of all these in the SaaS ecosystem.
I agree with you because we see FinTech companies coming up right now, not only because of crypto but also because of open banking; as you mentioned, we also have similar things here in Portugal, and that will create a fascinating mixture of cultures. You’re putting together speed and agility. Let’s fail fast, but let’s also develop quickly. And at the same time, you’re working with highly regulated markets, very sensitive information, and a lot of privacy concerns. And this is a huge challenge. And a lot of companies that are, if not all, companies that work in that space will need to address those challenges quickly. And there will be a time when regulators will understand that, eventually, they need to do their regulation differently and fix that first because the old ways eventually are not fast enough.
And at the same time, some companies will understand what they need. I’m not saying they are not right, but they need to take security even further than the regulator asks. Because at a certain point, just compliant will never be enough, like I said in the beginning. You need to use the need to comply, build a baseline, and start growing from there. And that’s something in a culture that is still shifting because many companies still need to comply. So, I’m okay, I’m complying with this. It’s then regulatory standards, and I’m doing this. You need to go further because regulators will understand all these companies are different. We need to be more demanding with them. And if they are not prepared, they will struggle for sure.