The value of Runtime Security for the financial sector: Why current Application Security approaches too often fall flat

Host: 

So today, we're gonna be talking about cybersecurity, application security, API security, and cloud security, especially as it relates to financial services organizations.

And before we dive into the specifics, what's working, what's not working, and what financial services organizations can do to be better, I wanna level set here. And, Tom, I'm gonna ask you to start us off. Can you speak a little bit about the threat landscape that's particularly impactful for financial services organizations?

Tom:

Yes. I mean, look. In the twenty five years I've been in cybersecurity, I've never seen it this bad. You know, we got geopolitical tension metastasizing cyberattacks across the world.

You’ve got four rogue nation states who have created a protection racket around their cyber criminal communities who are launching significant, if sometimes destructive attacks against the financial sector. And then most importantly, the modus operandi of the cybercrime cartels out there has shifted away from just burglary to actually home invasion. What I mean by that is they effectively want to compromise and hijack your digital transformation and use it to attack your constituency, whether that's your network, your application, or your cloud. And so it's imperative that we change the way we conduct cyber vigilance in this space and really evaluate how they're attacking us.

And to that point, tactically, they're really upping their ante on application attacks. We've seen a fifty percent increase in zero days released into the wild and exploited over the past year according to Google Mandiant. We're also seeing that the average application out there is getting attacked eight hundred times a day. That's crazy.

I mean, eight hundred times a day an application is being attacked. And so we need to appreciate how we need to best defend these applications from within, how we can create partnerships like the one you're gonna be speaking to today, to better insulate the ecosystem of the financial sector from these types of cybercrime cartels. One more point, though. I think the trends in electronic fraud have also shifted.

Having been the CISO for the World Bank back in the day, wire transfer fraud used to be the primary SALT mechanism, the primary conspiracy leveraged by cyber criminals. It's no longer the case. Actually, they're conducting much more intricate cybercrime conspiracies. One such one is essentially digital front running where they're going to steal non-public market information or market strategies from financial institutions and use that in the markets to benefit their portfolios.

In addition, there's this crazy new trend called shoxxing. Yeah. Shoxing, where they essentially compromise a financial institution. They then short the stock, and then they dox sensitive confidential information from that institution to the regulators or to the media, thus causing chaos in the market for that stock. So we need to pay attention to how they're changing and allow offense to inform defense.

Host:

Yeah. It's pretty wild out there. Eric, I'd love to hear your two cents. I know you have a really interesting unique perspective. Is there any other sort of key issues, key threats that financial services organizations need to be aware of?

Eric:

Yeah. You know, it's fascinating to watch. So I've actually been back at AWS. Second tour of duty for me, actually, from, from 2017n where I built and did a lot of work in the public sector space around FedRAMP, the DOD SRG, Impact Level x, and helping clients implement those types of regulations into the SaaS workloads that they were looking to go and deploy. And what kind of brought me back to AWS was the financial services market was basically in a stage where they were saying not an if, but a when and how quickly can we actually move to the cloud back end. And what that obviously turns into is it creates a massive ability to drive real efficiency in infrastructure networks and compute optimization utilizing cloud services to power those workloads.

But if I almost feel like I'm doing it wrong without showing the shared responsibility model as part of this presentation because it's something that we constantly talk about at AWS if you've ever been to a presentation. But it's very, very important to kinda think about that because the banks typically, the financial services market had a lot of different ways that they were isolating and kinda managing that type of risk and security vulnerability kind of assessments across the board, whether it's the app layer, the infra layer, and everything in between. And now we're at the place when you look at the infrastructure AWS provides, security is obviously always job zero.

Right? That is our most critical aspect of the way that we build the infrastructure from the hypervisor on down. But when we look at what teams are gonna utilize to really deploy or migrate these workloads over into AWS and then to start to decompose them, we start to see a pretty heavy explosion in the code that actually is created to really drive that type of emotion.

And it's not just what types of vectors can we come into and kind of the classic way these attackers were moving in. It's more that we've got a lot of application logic now that creates a lot more openings for different types of threat actors to get in the actual workloads and really cause a lot of chaos. And the other part that's kinda fascinating coming into financial services from the public sector space is while there are published compliance regimes to protect against these types of motions, every bank kinda does it a little bit differently. Right?

It's not really that they follow the guideline, but everybody has a certain level of ways that they're gonna kinda customize that. So the dialogue that we get into a lot, given that lots of application type scanning technology has been out there for a long time to make sure that we're not introducing vulnerabilities at the app layer, complementing what we're doing at runtime. What we're seeing a pretty heavy explosion in is, well, as I'm really moving those workloads over in AWS, I need to protect myself because the way that I'm implementing the control frameworks in the shared responsibility model, automating the compliance guardrails to say we are meeting the specification of the office of the system for this particular application, this particular workload, et cetera, it's becoming critical for clients to be able to actually harness and bring together what they've been doing.

And that's posed quite candidly a pretty wide array of areas where we need to to help them quite a bit. Because when we have a lot of point solutions and we have a lot of different ways that this has kinda grown up in these investment houses and banks, we need a way to kinda create more standards in how we enforce those. And that's been something that we have worked very diligently with the client bases on given that this is a pretty new frontier for a lot of them, and and we need to kinda help them really wrap and harness how they're gonna not just move these workloads into AWS, but do it in a way that's gonna constantly increase their overall compliance and security posture in in in a more positive way as we move forward.

Host:

Yeah. Tom, I wanna go back to something you had mentioned, you know, particularly when in relation to the issues that financial services organizations are facing.

Increasingly, we're seeing both the application layer, the APIs and the cloud environments are increasingly being targeted. Can you speak a little bit, especially at the application and API point of perspective? What are financial services organizations doing to safeguard their applications and APIs, and what is and isn't working?

Tom:

Sure. API attacks are exploding. We have to appreciate that. No one really knows where they end and begin metaphorically. It's highly problematic. And most importantly, if the API is compromised, you can essentially burrow your way into pretty much anything. And so much more attention needs to be paid to API security. 

But in general, most financial institutions are trying to align with compliance regimes. Compliance regimes that are specific to legacy solutions to this problem, legacy solutions that are just snapshots in time. Either they're using SAST or DAST tools or or they're using WAFs to protect the application itself, but WAFs are ineffective against back-end system attacks or ineffective against expression language attacks, etcetera, etcetera. So when you're using SAST and DAST, you're basically telling me at this point in time, this is what's occurring, but there's no context, and it's not continuous or dynamic in terms of the assessment process.

And per what was said earlier, we need context and runtime. That's where the app, the vulnerabilities are being exploited. That's when the adversaries are burrowing in. We need to understand what are the adversaries and not only use that as a vector, but if they move laterally through the application, whether they maintain persistence in that environment and how they're attacking the rest of the organization.

One fun fact, I mean, based on the Verizon Data report that was just released, 55 days after a patch is released, only half of critical vulnerabilities are addressed. I mean, that's just shocking, but, obviously, there's too much debt. There's too much vulnerability debt and management debt, and that's what we're trying to solve with this partnership here today.

Eric:

Absolutely. And, Tom, I'd love to just expand on that a little bit. Right? So I've kind of been in this software development space for the better part of 20 years, which I guess you can start to see some of the gray.

You can obviously imagine. But, it's kinda wild to see the kind of paradigms kind of move forward. Right? So when I first kinda got into the whole cloud landscape, we saw a pretty heavy explosion in just open source consumption.

Not that it wasn't being done, but people were realizing we've got 99% of our production workloads with some form of open source or open source dependencies. We better put some governance around how developers are consuming those packages and using that code.

And in that same context, you saw the kind of SAST and DAST scanners grow out of that as well as kind of scanners for where open source logic lives because people need to pay attention to it. And it really was kind of happening out at the developer ranks. We can call it shadow IT. We can call it just teams needing to be able to move more quickly.

They really did go down that route. And make no mistake, that has been a very positive thing to really accelerate adoption, accelerate migration, accelerate transformation for the development teams. But it also poses a pretty heavy level of additional types of risk that people need to go watch out for. Right? And we've seen, obviously, that be a very core focus.

And one of the things that becomes a challenge as we look to see what those scanners do at the app level or at what open source components are being utilized. We've seen a pretty heavy need to really go and scan those packages and components.

But over the course of time, developers have built lots and lots of different ways that they address that problem even though there is, quote, unquote, a central DevOps team or a central security team that's watching for it. The information of how we package those scans is critical, but what happens a lot of times is the CISO gets the scanning results when we kind of build that bill of material up and kinda look at the supply chain of artifacts that are going into these software applications, and it's daunting. It's a lot to go fix. It's a lot of technical debt that's in front of them. 

And you mentioned APIs. APIs obviously are really, in my opinion, the next iteration of what we've seen around the open source economy and kinda classic code examples.

We are seeing a dramatic explosion in developers consuming, sharing and collaborating on the creation of APIs in their environment. And we've seen a lot of interest in customers saying, we need to get a handle on this part now too because APIs not just are a strategic way for us to drive transformation and the overall application and workload estate, but they actually represent a way for us to drive maybe new routes to market, and we better make sure that that is secure and that we've got the actual necessary governance around when those calls are being made. And we've seen a pretty heavy shift when we're looking at the amount of technical debt when you think about the API landscape, the open source landscape, the number of workloads and applications that developers are working on that are pulling open source components, we need to make sure that we're actually watching everything that's being created and bundling it in a way that is really feeding to the system to say we need to fix these problems.

But we need to fix these problems is a great thing, but does that mean that we're gonna wait a year, two years before we release these features out to a customer? That's also an untenable model. And we've seen a pretty heavy level of interest in, how do we protect it in run time at the app layer now, at the API layer now, at the code layer now, while we work to protect ourselves and get stronger at the discipline of modern software delivery that incorporates a lot more of these kind of more modern techniques around making sure APIs are integral, secure, consumable, and the right ones, same thing with the code bases and the same things that the new features their development teams are actually creating.

Tom:

So shift right to shift left, essentially, like a DC traffic circle.

Eric:

You gotta take a right Yes, sir.

Host:

Yeah. Eric, I'm curious. One thing that I hear and would love your perspective on this: There's, as you mentioned, compliance is always gonna be a really big part of how financial services organizations are thinking, including and beyond cybersecurity. There is a perception that you need these SAST and DAST tools, these kinds of legacy tools, in order to meet the compliance requirements and what's being asked.

And yet there's also the sense of especially something like SAST that produces this huge list of vulnerabilities. It's just adding to the technical debt. There's no way to prioritize which ones are actually critical, which ones are not.

It sort of seems like there's this understanding that the current system isn't working, and yet the current system sort of keeps going. I would love your thoughts as to, why are we continually using these tools that we know are not ideal? Is it just compliance? Are there other reasons at play here?

Eric:

You know, I think we can look at a few different things. I think when you look at the historical way a top 20 global bank grew up, right, you've got everything from mainframe to serverless and everything in between with large tranches of development teams, sometimes to the magnitude of thirty, forty, fifty thousand engineers working on different applications that are supporting the way the bank is gonna run, the way they interact with customers, etcetera. And that is only growing in kind of the digital channels that banks need to be able to drive out and really work within. Right? Now we couldn't operate if we didn't have tooling infrastructure to support lots of those different systems.

And we also couldn't operate and ensure for a CISO that we were doing the necessary things for application scanning and open source scanning, infrastructure scanning, etcetera, to make sure that we know where we may be vulnerable because this is a sport. This isn't something that we just do and then we're done. We constantly need to be iterating because threat actors are constantly iterating their way that they're gonna be coming in. So I think on one side, we're not walking in and seeing these banks basically overnight saying, yeah, you know what? All that the way that we kinda run all that stuff on the mainframe, we're out. That's not happening. Right?

That's a journey as we work with these banks to really modernize, to be able to get better at supporting the customer, digital channels, transforming the way that they're gonna operate in this modern context. Right? So on one side, you have a lot of tooling and discipline that's just grown up and is very hardened into the way that the bank operates from an IT and a development perspective. What we've taken the approach of in working with these customers on the AWS side, as well as working with partners like Contrast, is we're in this kind of phase of not if, but when and how quickly. 

And what that breeds is not just, come talk to me about the breadth of Legos you have AWS, Legos meaning services, the scale, the regions, the availability zones. That's awesome. That's great. That actually shows us that you really can support us, that we've got ways to really run the type of infrastructure that is required to power a global top twenty bank. We can support that. 

I think that what we've seen though is also well, AWS, you've been doing this for a while. So if you have this great service portfolio that powers infrastructure, you also have the largest set of developers in the world, set of startups in the world, set of different financial and different types of customers that have implemented AWS to transform their back end in a very sophisticated way.

So if we're gonna look at the infrastructure side of this story, we're also at the exact same time helping them realize that we may need to modernize some of that legacy tooling that we've been growing up with for quite some time. Right? Both from a more efficient kind of way that we operate in a lens that way, but also in a way that helps us get better at the data aggregation. 

One of the biggest challenges that the kind of discipline of DevOps implemented was, we do have a lot of point solutions. We may have teams that are out there thinking that they are agile and have implemented one of the most modern sophisticated DevOps pipelines in the world, but it's at the team level. And when we start to scale that out and look at that type of breadth of fifty thousand engineers, we are now being asked to help us streamline these operations.

But, again, just like we can't walk into Midtown Manhattan and say we're gonna go build overnight a brand new highway that's gonna take us out to Long Island that everybody's gonna go love. Right? I can actually go and say, we do need to recognize that the need for that is there to modernize. Therefore, we need to help consolidate a lot of the tooling we're using in the software development discipline so that we can get more efficient in the way that we're actually leveraging the cloud backend from a cost perspective and from a security and a risk perspective.

And what that has bred is we need to consolidate and look at more modern tooling architectures in the software development and the DevOps domain that help us really maximize the way we're gonna transition these workloads out to the cloud platform.

But to your point as we've been describing, a lot of those scanners are gonna throw off a lot of information because you're gonna find vulnerabilities in what the application developers have built. You're gonna find vulnerabilities in the open stores. You're gonna find vulnerabilities in the way we've configured containers, etcetera. And we can go down that list.

Then if I can show a CISO where it is, that's a very powerful thing to be able to do. But that also means that we gotta do something about it. And if it's two years or three years before we can say we've done something about it, that's too long. And that's where we're seeing, well, let's help you get the visibility that you need as you modernize this software development and DevOps estate, but let's not do that at the expense of the speed at which we can actually help you protect at runtime that workload, that set of software that you are running so that your customers can start to really take advantage of of kind of these modern digital channels that we're building. Right?

And, Tom, I don't know if you have anything you wanna add or thoughts there, but that is very much what we've seen.

Tom:

What you said is spot on. I mean, the CISOs’ out there looking for ground truth. They've always been looking for ground truth for the last fifteen, twenty years. They've achieved network and endpoint level with NDR and EDR and now XDR where they have telemetry, and they can continuously monitor for behavioral anomalies in those environments.

But they don't have that at the application layer. They don't actually understand what's going on in runtime, what's occurring within the application or against the application in runtime. And that's why I think it's imperative that we evolve just like the adversary. We have to evolve to include behavioral anomaly detection at the application layer.

We need ADR, but we need to be able to do that in a continuous fashion. We need to be able to continuously monitor the application layer for behavioral anomalies in runtime. That is the only way we're gonna deal with the scourge of zero days, nation state actors, and cybercrime curtails in 2024r.

Eric:

Yeah. Totally great. And I think one of the other things that I would love your perspective on, but we've seen quite a bit, is observability has always kind of been at kinda log analytics. We're obviously managing who might be trying to access or what's happening with the workload.

Maybe we're looking at performance. Maybe we're looking at infrastructure performance, etcetera. And it's kinda where it's always lived. And then there's been this other set of kind of security compliance wrappers that we're monitoring against as well.

But one of the things that we've heard from customers quite a bit is, well, as I'm modernizing this software development estate and as we may be doing some tooling consolidation or building in release orchestration mechanisms to bring all the data that's happening from the various continuous integration runs that are going, the way we're scanning the new features, the way we're scanning for open source and packaging that all up through a release orchestrator. Being able to feed that into that observability layer gives us a correlation mechanism to say we're protecting it in runtime, but that this is what we did. Right? 

This is what we've actually found. And we have found in speaking with a lot of customers in partnership with the Contrast team is that this story is actually incredibly impactful because if I deploy at runtime and I put a runtime wrap around it, I can protect. But if I can deploy the information on what scans went in and where I know those vulnerabilities are, that actually gives me a direct way to prioritize the way that I'm gonna go and fix the different things that are being thrown up. Because I can see it in runtime that maybe we've got some type of a vector that we're protected against using this layering, and we better go make that a quick fix back to development as fast as we can given the ever changing landscape of how those threat actors are trying to get in.

Tom:

And given, you know, people might be skeptical. Like, look at the latest Verizon data breach report. There was a three hundred percent increase of the exploitation of vulnerabilities as a primary attack vector last year. I mean, that's crazy. And you see adversaries embracing this. They're embracing the fact that they can hijack our digital transformation.

So we need to be vigilant.

Eric:

Yeah. Totally agree.

Host:

Yeah. There are some banks and financial institutions that are hundreds of years old. And, Eric, as you mentioned, they're gonna have mainframes and floppy disks maybe, hopefully not, and, like, very outdated technology in existence with very new and very modern technology. 

And you're steering a cruise ship. Right? Like, you're trying to turn the Titanic around, and that's not gonna happen overnight. You know your application security, your API security, your cloud security frameworks, the way that you're doing things is gonna have to change, but it can't happen overnight. And I almost think runtime security is kind of implementing bumpers. It's kind of protecting you from the iceberg as you're trying to turn the Titanic around.

I think that's really great advice, and something that sounds like financial institutions could do today to ensure that their application, API and cloud security can become more modern and protect against the current threat landscape. Are there other pieces of advice that you would offer financial institutions looking to better safeguard their applications and APIs?

Eric:

Yeah. I think that as we see these groups now saying, hey, we may have a set of five hundred applications, thousand applications, fifteen hundred applications that we're gonna be moving over to the platform. You know, one of the challenges that we've seen emerge is, well, if I go back to that shared responsibility model again – I wish I had a picture of it. It would definitely fit the job's description – But what's really important is what is in the blue is really what keeps those different communities up because we know that I need to inject a number of things in that compliance security role that really protect me when I move that workload into AWS. And, oh, by the way, workload into AWS. And, oh, by the way, a lot of companies are doing it already with the assets that they have on premise. There's just a little bit of a mentality that, well, you know, this is the way I've always been doing it. Right?

And they're used to the timeline of maybe we've gotta harden that environment for six, seven months and be able to kinda do those types of things. But what we've seen quite a bit from the customers is that that doesn't work for their customers. That timeline, that ability to innovate, is an untenable model for them as they're moving forward. They need to be able to get faster. They're all competing for various different customer segments, and they want to be able to be and serve those groups as best they can.

And cloud is viewed as a massive accelerant to be able to get them into a more agile and iterative state in the way they're thinking about releasing those features. I think one of the things that platforms like Contrast provide when we think about runtime is it's taking the problem and it's saying, I know that we've got a lot of chaos over here on the development side. We do. Like, that's a fact.

And I know that it's as we work to modernize our cloud estate or workload estate on the cloud, I should say, that we're going to do something about this over here on the left. We're going to fix this. We're going to consolidate. We're going to bring things together.

But I don't want that to be the reason why I'm waiting a year or two to move these five hundred to a thousand workloads over in AWS because there are platforms and solutions that offer me that level of protection while I modernize. And what that does is really opens up for the client an ability to start moving down the path in an infrastructure-as-a-service capacity with Amazon.

It provides an end-to-end way for them to start really maximizing moving capital expenditure to operating expenditure, really reducing thirty percent of the overall run time cost of that workload because of scalability and elasticity.

And then it becomes a conversation of, if I can get you that savings and create that layer of protection, we can start to work on iteratively running that workload, helping you make it more cost efficient while we actually take that savings and apply it back to modernizing the overall estate on the software development side. And it creates a flywheel within the business for them to be able to operate in a much more efficient modern way that the cloud promises, whether constantly increasing their overall posture from a security and compliance perspective and from a cost savings perspective.

Tom:

Well said.

Host:

Tom, would love your two cents here. What advice would you give to financial services organizations looking to improve their security posture?

Tom:

Yeah. I mean, first and foremost, I would acknowledge much of what he said is that, you know, in particular, not all cloud infrastructure providers are equal in terms of the diligence and the attention they pay to cybersecurity writ large, even the journey in that regard, which is why I'm proud to be partners with Amazon.

But I think, you know, we really need to extend the lessons learned by the CISO over the past twenty years away from perimeter defense to detection response and extend that into the application layer. Can they continuously monitor for behavioral anomalies at the application layer? Can they respond, react and protect against those manifestations of these adversaries? The financial sector writ large is being targeted by the most sophisticated cyber criminals and spies in the world, and we need to appreciate how their game can inform our defense.

I do think ADR, application detection and response, is here to stay. I think it's important that that visibility be achieved. Ground truth into the application layer is something that CISOs should now be aware that they can have. They can have that now. They shouldn't be so reliant on those snapshots in time provided by SAST and DAST vendors.

In the end, it's all about vigilant digital transformation. I think this partnership exemplifies that to a tee, and I look forward to having greater conversations with the financial sector further. What keeps them up at night, but more importantly, how we can better defend one another in that shared model.

Eric:

Yeah. Tom, full stop agree on all fronts. And it's been a fun process to go and really use platforms like Contrast and partnership here as a a a a level of protection and guarding while we're helping the client really accelerate time to value in the AWS back end.

Host:

Great. Well, we've covered a lot of great territory, really fascinating insights here. Appreciate the practical advice as well. Any final comments, final pieces of feedback you'd like to offer today?

Tom:

I just wanna leave you all with a quote, from one of my favorite movies, The Usual Suspects: “The greatest trick the devil ever pulled was to convince the world he didn't exist.”

And that devil is somewhere in your application layer.

Eric:

That's a good one, that movie was ruined for me before I actually saw it. I'm not ruining anybody from the audience if you haven't, but please go watch it. What a twist. 

But Tom, I couldn't agree with you more. I think that the way that technology will just constantly evolve, there is always going to be a need for this type of runtime protection because we need to be able to find, isolate and understand where these new threat actors are coming, and we don't know where they're coming from because it's constantly going to evolve. And then you look at, you know, what AI is providing on top of that to be able to just go and run different bots to exploit, etcetera. You know, there's just brand new frontiers that are in front of us. So the interesting thing is this will constantly evolve and change.

The good news is we, as an AWS infrastructure provider and platforms like Contrast working in tandem, allow clients to stay ahead of that by really creating these isolation components in the way that they're thinking about moving. And then we get to work with them on the other side of the coin from a development perspective to improve and get better at not just building quality software, but doing it in a way that's constantly iterating on the security compliance injection process as well as being able to take the data and get more robust information to the observability layer to watch what's going on, but also use that to improve overall posture and process as we continue to help the clients maximize value of the cloud back end.

Host:

Fantastic. Well, thank you both. This was a great conversation. I certainly learned a lot. And for folks tuning in, I hope, you all did too.