The biggest cybersecurity risks in the financial services industry

Ransomware, SQL injection attacks, and cross-site scripting are also serious cybersecurity risks for banks and brokerage firms, according to a new study.

The biggest cybersecurity risks in the financial services industry Ransomware, SQL injection attacks, and cross-site scripting are also serious cybersecurity risks for banks and brokerage firms, according to a new study.

A new study reveals some important findings for companies in the financial services industry when it comes to cybersecurity.
TechRepublic's Karen Roby spoke with Drew Kilbourne of Synopsys, about the results of the survey. The following is an edited transcript of their interview.

Drew: We've been working in the banking industry for about 15 years. And we really wanted to kind of go out to the broader spectrum of companies in the FSIs and really understand if what we were seeing in the industry with the larger banks and brokers houses was true across the entire spectrum. It proved our findings through the years.

Karen: Talk a little bit about some of the highlights, some of the things that you guys discovered in terms of the technologies that posed the greatest software security risk to companies in these types of organizations.

Drew: Well, the one thing that was most interesting was across the population that we interviewed was over half of them are still seeing significant cyberattacks or data theft. It's interesting because we've been working with the larger banks for a lot of years. We work with 16 of the top 20 banks in the world and feel that their programs are pretty top-notch and that they've done a good job of building holistic programs to secure their software.

But yet, still half of the population are seeing problems. When you dig into the report, you see that one of the big gaps across both big banks and small bags is third party software. So people are not dealing with their third party software risks well. They do a lot of third party assessment, but it usually includes evaluating if you have locks on the door or if your firewalls are up, if you do background checks on employees, things like that.

But generally, those third-party programs don't dig into software quality in software security. When you break that apart and you say as an industry as a whole, and the survey proved that, that a very small percentage were actually dealing with third party risk, although they felt that it was a big problem.

This impacts the mid-tier and smaller financials much more. They buy a lot of software more than build software. So now you can see why you get a number like over half are still experiencing attacks. There was a lot of companies out there that buy software, and they're not evaluating it well. That was an interesting finding there.

SEE: 27 ways to reduce insider security threats (free PDF) (TechRepublic)  

Karen: With regards to regulatory requirements, are they keeping pace with the changing technologies such as blockchain?

Drew: We would wish that there was a set of requirements that you can test against in the financial industry. That the good news is it's the most regulated industry, I feel. And that has created a better security posture in the financial brokerage market. But with that said, the way the regulations are written and the way the regulations are evaluated are very, very different. They're not just a clear cut; you must do X, Y, Z.

So what you end up with is a regulator that sits in your bank and they sort of determine if you're managing risk appropriately. The way the banks do that are very different bank to bank. Some may rely heavily on penetration testing. Others may rely heavily on design review. Completely different methodologies, yet the federal regulators will say, "We bless you and you're managing your risk well." I think it's okay when I look at those banks and what they've done.

So regulation is a tough one to hang your hat on. The one that that has I guess, some level of teeth is PCI. The problem with PCI is it's a shallow bar proven by the fact that the largest hacks in the industry, Equifax, Home Depot, Anthem, Target, all were companies that pass their PCI audits. So PCI is trying to put more teeth into the next set of regulations. And one of the things I like, what they're doing is they're going to specify that you have to have a software security program.

And the program goes beyond just testing. The program is about policy. It's about governance, about use of tooling in the SDLC. So I think through that we'll get a better regulation there. Although I still feel the bar will be pretty low and that companies are going to still have to step up and manage this risk on their own.

Karen: What types of threats and actual breaches are companies experiencing?

Drew: We didn't go into the impact of the breaches. We dug into some data around was it PII theft, or was it ransomware? Surprisingly enough, I think over 30%, about 38% were ransomware attacks. That becomes something that's kind of new and novel in the industry. I didn't realize that that was that big that people are taking control of people's environments and demanding cash or some level of payment.

But we didn't go into specifics of exactly how the attacks were done, or are there common mistakes that people are making? We are still seeing common mistakes in our testing with the big banks and in the mid-tier that we work with, most of our clients that do any web software development. That still, you have the OS X, pretty prevalent out there in software. So a lot of sequel injection, cross-site scripting, which are easy, easy attacks for people to play on and get into the systems and then attack the software.

So that to me, is still pretty troublesome out in the industry. And the report proved this that companies still aren't doing enough developer enablement, training, and whatnot so that developers will stop making these same mistakes over and over again. We're very good at finding. We're not good at fixing and preventing as well as I'd like to see.

Karen: What do you recommend companies do to stay as safe as possible?

Drew: One of the things that came out in the report, in particular, and spoke to the third party software problem that I was talking to earlier, is an open source. So open source is very prevalent through all software. People use it in the old software they develop, but also, it's heavily used in the software that they buy. We found that not many people, and I think it was in the low 40s, were even dealing with open source from a perspective of inventoring it and understanding what they were getting in the packages they were buying or the software they were building.

Moreover, very few, I think it was about 15 to 20%, were using tools to understand what's going on in their open source and being able to manage it. So if you couple that with the fact that we have an audit group that does a ton of open source auditing throughout the world every year, what we found in those audits is 60% of all open source have security vulnerabilities and then that over 40% have critical security vulnerabilities.

So we know the open source in the market have bugs. People are absorbing that software into their enterprise, but they're not looking at it. They're not evaluating it, and they're not understanding it. Right? So hence, you have a very big problem from that intake method. So we think people have to get their arms around open source. It's great you can put a tool in place, and that's a solution. You need to build a program around that for what you do when you find those vulnerabilities in software that isn't scheduled for release this year.

How do you fix it? Do you fix the software and re-release it to the market? Do you wait for the market to release it back to you? How do you get all of your other software off the shelf and fixed and re-released? To me, that's a big problem that the industry has to deal with. And it goes along with this third party problem that I think is not helping the industry along.

Karen: In terms of the percentage of organizations that seem to be concerned that, say, a malicious actor may target their software. How many seem to be worried about that?

Drew: I think they're all worried about that. They're all trying to put walls up where they can. There's a lot of still network security going on to try to block people out. But the realities, in the end, you open yourself up to let people come in and do business with you, and then you're in the software. So I don't have any customers that still aren't worried about data breaches and breaches on their software and trying to protect it.

Karen: Were you surprised by the findings of the report, or did you expect these results?

Drew: The thing that was a little surprising to me was people still are relying on penetration testing at the very end of the cycle to do most of the work and finding defects. Although, in the bigger FIs that we do work with, we've seen them starting to tool in the SDLC, applying static analysis tools and dynamic analysis tools and interactive analysis tools, all sorts of different tool in the SDLC. And that's beneficial. And I think it's being driven by the move to DevOps in the industry.

Still, the study says that a very small portion of the FSIs are using tooling in the SDLC. So it's still the primary methods for finding bugs is waiting to the very end, and then try to test. The problem with penetration testing is they're fixed timebox tests. You can't possibly get enough coverage. Really, you need to use your pen-testing through your business [inaudible 00:10:32] testing so you won't be finding and looking for your SQL injection, cross-site scripting, and those things.

They could be stripped out earlier in the cycle way left by tooling. So I found that that was kind of interesting because personally myself, we've deployed a lot of tools at the big FIs, and that's worked well. But I was surprised in a survey of 400; still a very small population, have embraced tools in the SDLC.

Karen: How do you make companies feel like they are doing all they can to protect themselves?

Drew: The interesting thing is, because I'm in a consulting organization, I see a bunch of customers. I can see wins, and I can see losses. So I have several customers that are very big, large banks that have completely reduced their cyber fraud to number three or four on their list of fraud, which to me is huge because other areas of fraud would be like ATM fraud and check washing and other things like that that surprise me still go on.

So they were able to do it. They've been able to fix their software. They've been able to push the hacks out. That gets me excited. I also have a customer who looked at this problem in a different way. They didn't look at it from risks. They looked at it at cost savings and development.

So I think it's really interesting because most of the pushback against dealing with security in software is it's going to take us longer and costs us more money. This gentleman surveyed his program after three years at a large healthcare insurance company. What they found was they're saving about $21 million a year in software development costs, which means they could do more for their customers, provide more value to their customers. And as a secondary benefit, he reduced risk in the enterprise.

So I like that he always sells his programs on dollar saved, which I think is interesting. He gets CIOs to back him and to get behind deploying tools and techniques and developer enablement in the enterprise because they see the direct costs benefit. I get excited to see if there are some good wins out there. And I get depressed if there's still some large banks out there that aren't doing as well as their peer sets. They still haven't got into central programs, and they're still doing things piecemeal.

It's an interesting industry that's pretty diverse from that perspective. But I think from broad strokes, getting their arms around third party software, whether you're big or small, I think will have a huge impact and open source software have a huge impact on the industry as a whole and securing the software in a better way.

Also see