API Security for Fintech SaaS | Getting the Most out of a WAF | Val Novikov (Co-Founder & CTO, FISPAN)

I’ve been building software products for about 20 years. I took the journey step by step instead of starting a business right after college. I developed software, lead the teams, and built engineering functions. After nearly 15 years of doing that, I co-founded FISPAN, a business banking SaaS product in the Fintech area. 

And I’ve been doing it for about six, seven years now. FISPAN has been the biggest product I have built so far. 

From the business side, banks struggle to innovate as they are not technology companies. They’re not like software development companies. They try occasionally, but they struggle with this. That’s why they reach out to fintech to help. Most of the fintech take positions very unfriendly to the bank. 

So, we took a very different approach. We said nobody will get rid of the banks because of the regulations, like somebody still needs to be the custodian of the money. Banks are there for a reason; they’re just a little slow and need help. 

That’s how the idea of FISPAN started. We looked at the banks and we looked at their customer base. 

Their business customers are the most underserved because a Bank’s service is complex. So, we looked at how to make it better. We are building a product that helps banks to retain business customers and provide them with a more modern banking experience. 

That includes tight integrations into financial and ERP applications like NetSuite, QuickBooks, Microsoft ERP, and Oracle products. 

And there’s a SaaS platform in the middle handling all the heavy lifting. 

There’s a good and bad side to compliance. 

We understood that compliance is going to be fundamental for success. Competition just doesn’t go anywhere. So absolutely, while building MVP, we put together compliance, and we started SOC certification almost a few months into the journey. And later, we had SOC Type 2.  

Then we achieved ISO compliance, and that was just kind of mandatory for our type of business. And we were just positive about it because we knew it would give us an advantage long-term. 

The bad side is that it slows business and requires more capital. It slows down for some good reasons, but some are annoying; you just wish you could move faster. 

The monetary aspect cannot just be dismissed. It could just cost a lot of money. You need to bring in consultancy, and you need to have somebody who is like doing the audits, and they’re not always the best choice and might give you a hard time. 

They might not understand anything about your area. These overheads always slow down the business. And you can’t afford that thinking when you’re young fintech. 

We always saw compliance as an additive to passing through the gates with the clients. 

This equity and fortification of systems and processes like risk assessment were completely separate from day one. And the way we were building, of course, all these were like security by design. 

“If anything leaks, we’re still secure” – let’s just design our systems this way. We took compliance, and sometimes we had problems because our protection methods were creative and extremely efficient. 

But compliance would not take it as sufficient from their point of view because they’re just used to seeing some sort of check box type of thing. And you will explain that, like by design, that removes that risk; it’s better protection, and they just wouldn’t get it. It’s a very frustrating experience. 

It’s a many-to-many system. So, imagine the complexity of the number of endpoints on each side. We integrate with many banks on the back and front end and build applications to connect to our systems. So it’s a lot of possibilities to leverage APIs and kind of like attack vectors. 

We are designing the APIs assuming that everything will be exposed at some point as the result of unintentional or intentional action by anybody. 

The exposure of any API is that it’s only so much risk by design. But as a best practice, you block everything by default on the firewall and some sort of public entry point and just allow the stuff you want. 

And typically, the biggest problem you’ll have is that some application releases wouldn’t work because somebody forgot to add the endpoint. To look at the list of the API because as a company grows and applications become more, especially with acquisitions. You might get more applications added and wouldn’t know everything about them. 

What we typically do is, from time to time, we would scan code and systems and use penetration testing tactics to identify what API is sitting and where. We have a good penetration testing team and rotate the teams for a fresh look at the layout. We will capture swagger files. 

I think expecting people to do everything perfectly is too much to expect at some point. We would expect people to fail at some point to do that properly, and we’ll generate it by contacting somebody externally. 

I understand it. I cannot relate to it because, for younger companies, it’s just unacceptable. There’s no way you can survive in the business in a fintech, like with those kinds of keeping expectations. In every contract, there will be SLAs for the client, like how fast you should respond. 

So it’s happening in the bigger company because I had worked for some of the biggest telecom companies in the world. 

The problem is that many of the products the companies are using were acquired/built years ago. Some of them sit on mainframes, and over time people rotate, the people leave the company, and nobody really understands what’s happening. They were built in the era of waterfalls like you have this project made in 2005. 

I remember I was estimating a project for like Australian Telecom Company. It was something like 15,000 mandates, and then we’ll figure out how to do things in parallel and break it down as stages.   

That was very common, and you just like planning every big initiative over multiple years and trying to work with it. That dictates the release schedule. A big release is a nightmare; it happens once half a year, like a few months at best, that’s how those projects were built, and that’s very difficult to change. 

So, when you have the enterprise that built-in fear of releases because it’s such a traumatic experience, they just don’t want to touch anything unless it’s up to the necessary. They don’t have the process to push things fast, like we are in Q1, in Q2 now they see, okay, Q1 next year, that’s going to be like that’s where our planning phase is still open everything else is closed. 

So essentially, the solution for this problem is always the same; just you need to move to transform your company towards more agile practices, like implementing, embracing frequent releases, embracing the problems like attacking them head-on, and the more frequently you do that, the better you become it. 

I’ve seen some very large enterprises, like 30,000 people working, and they would be able to accomplish it team by team, and then you start seeing as a completely unacceptable 200 days, moving into something like 60 days. 

Yeah, absolutely. It’s just like it’s a good component in the magnitude of measures you’re taking.  

As a CISO, or whoever is responsible for the company’s security needs to plan for every failure and estimate the risks. 

So, we would assume that the security can fail, so our API would be exposed, assuming the API can fail. So we have the firewall to cover up for this.  

We’ll assume that encryption might break at some point, so what kind of data we’re sending there can be switched to tokens instead of sending the raw data. You need to scan for all possible failures and can design for that. 

You bring in people with expertise in a certain area and ask them to challenge you, like people who deal with those security challenges day and night; that’s generally very good practice because there’s always something you don’t know. 

For evaluating the web application firewall, I would be looking at things. First, credibility is very important. So, you can’t just pick a product; it’s like you’re going to be the first user and integrate it into your product because it’s the only option. It’s typically just a wrong decision. You want to see some credibility. 

Performance right out of the gate, like you will disqualify products immediately, is not the most important thing in evaluation. But if you don’t have it, there’s no point continuing. 

So like, I would try to see some proof that scale is working, what’s the overheads and milliseconds different stages. 

Then a super practical challenge for firewalls is out-of-the-box rules, like who designed them and how much support we will have in keeping that firewall running. 

Because it typically comes with a human cost, like you’re purchasing a firewall, but the biggest overheads will be how many people will be managing it. 

Supporting, troubleshooting, maintenance costs, out-of-the-box rules, and hints like how previous customers had experience with that company, like managing it. 

And as a rule, it’s like I represent a technology company; I don’t want to be in the business creating a firewall, right? 

You just can’t do everything and should be laser-focused on your business. I should understand it to lead that correctly, but I shouldn’t be doing my own firewall. 

So I would like to work with an expert who thought about the rules and best practices and then bring it up to the table. 

I the last one, I say deployment options are very important because you mentioned in a previous question how we deal with situations when things are not in our system with those third-party components. I think this and that’s where it depends on how important security is for you. Like in the banking sector, it’s the utmost priority. 

So our design choices had to be assuming that it would happen, and you cannot act like you were surprised one day when it happened, so we went with a very granular service like infrastructure provider AWS. 

This is the biggest reason we didn’t use a Google Cloud because the granularity of your configurations, network configurations, and level of control of the components is extremely fine-tuned. You can go at any level you want, which drives our choices because we want to be able to carve out problems ourselves and mitigate them while waiting for the solution. 

Switch to an alternative service. And yeah, when it comes to firewalls, we even use some sort of firewalls on different levels, like another type of firewalls, and we’ll have backup options. 

I’m a big believer that people should understand how things work at a pretty deep level. Because if you don’t, you can’t evaluate the strategy. 

You’re relying on people doing just their part of the job. They’re not always communicating properly. You need to understand how things work. 

Suppose you’re considering taking a leadership role in security technology. In that case, you’ve got to take some courses to understand, like comprehending what penetration testing looks like, how people will breach in, and what kind of techniques they’ll try. 

Remember that technology is only part of the equation; try to read about it, see what techniques are used and do some exercises. 

Let’s say maybe if you’re a developer. Try to configure security scanning on the different levels into your CI/CD and, like, try to run them from your computer to see what kind of outcome comes in and whether it is readable, valid, or noisy, like understanding those things. It helps tremendously once you take a leadership position. 

Because ultimately, you’re going to be responsible for hiring people who will be doing this job and evaluating their skills. All you need to be able to ask questions, and you need to challenge some choices. For instance, I expect the team to develop the best answer, but I’m responsible for the outcome anyway. So, I will need to challenge the choices like 

• Why do you think this way?
• Have you considered any other options? 
• How many did you consider?

Being able to ask questions is the most important thing for leadership. And you cannot do that effectively after taking a management course on leadership. You must roll up your sleeves, take some courses and understand how it works.