May 08, 2024

00:35:53

Episode 255 Deep Dive: Jason Baden | Simplifying API Security: The Impact and Evolution of Secure Application Development

Episode 255 Deep Dive: Jason Baden | Simplifying API Security: The Impact and Evolution of Secure Application Development
KBKAST
Episode 255 Deep Dive: Jason Baden | Simplifying API Security: The Impact and Evolution of Secure Application Development

May 08 2024 | 00:35:53

/

Show Notes

Jason has almost 20 years’ experience as a senior executive in the IT and telecommunications industry. Prior to joining F5, he was Country Manager at Ruckus Networks and was responsible for leading the ANZ team strategy, as well as the smooth integration of ARRIS following its acquisition of Ruckus Networks. He has also previously held roles at Juniper Networks, AXS-One, Airwide Solutions, and Optus.

View Full Transcript

Episode Transcript

[00:00:00] Speaker A: Every time you're talking about security, whether it's physical, whether it's application or it's virtual, is that the lowest one is the one that is the easiest to target. So almost everybody has to have the same level of security to make sure that they're not being breached. [00:00:19] Speaker B: This is KBCs as a primary target for ransomware campaigns, security and testing and. [00:00:26] Speaker A: Performance and scalability, risk and compliance. We can actually automatically take that data and use it. [00:00:34] Speaker B: Joining me today is Jason Baden, regional vice president, ANZ from f five. And today we're talking about simplifying API security. So, Jason, thanks for joining and welcome. [00:00:44] Speaker A: Thank you so much, Carissa. Great to be here. [00:00:46] Speaker B: Okay, so let's start with exactly that. So what is your view on what does simplifying API security actually look like? [00:00:54] Speaker A: Sure. So I think API security over the last five years has really changed. It's been a really interesting place for the whole entire market. In regards to APIs, previously were not really talked about, they weren't really known. And as we've continued to evolve applications, APIs have really come to the forefront. I think if you ask someone on the street that now they know exactly what an API is, and they, in the sense that they know that that is something that could be vulnerable or it could be exposed or could have some security issues. So what we're seeing now is that across the board, APIs are much wider in the overall business context. And where this was traditionally just a security conversation has now opened up much wider. So what we're seeing now is that traditionally talk to a security consultant. They're talking about APIs, they're building out their application. Now what we're seeing is that the senior leadership of an organization or board members and say, we want to know about APIs, we want to know how many APIs we've got, we want to know where they sit, and we want to know if they're secured or not. [00:02:00] Speaker B: Okay, so there's a couple of things in there that you said. So you said originally they weren't really talked about. Why do you think that's the case? [00:02:07] Speaker A: I don't think anybody knew what they were. I don't think we had that level of interaction between where an application was sitting and who it was talking to. Traditionally, an application would sit on Prem, it would be very static, it would be not looked at that often. It would do the same thing over and over again. And if you think about a large bank, they would have that application sitting in a mainframe and that didn't have a lot of interaction outside the organization. Applications have continued to evolve. Now what happens is that you've got other computers or you've got other applications looking in to get information out of those, and therefore there's those interactions that are going on. [00:02:43] Speaker B: So would you say, Jason, API has made a bit of a resurgence post the telco breach here in Australia? [00:02:49] Speaker A: I think that what it has done is it has increased the conversation in every organization. Anybody who's got an application that is outward focused, that any security breach brings it to the forefront. And I think the extent of some of those security breaches that have occurred has meant that now a lot more people want to know exactly where that is. What I have seen from talking to traditionally, we've been talking to security leadership. So chief information security officers, security leads, they're the traditional people that we would discuss API security with. Now what happens is that we get the board discussion or there's a senior leadership c level discussion about where do our APIs sit? Are we secured? Does everybody know where they are and what they're doing? Now, what we would see in that scenario is that privately there is always a concern is that do you have coverage of absolutely everything? Can you give a hundred percent commitment that that's covered off? That's not always possible, and that goes back to discoverability. [00:03:51] Speaker B: So what's the conversation like now? What do people want to know? [00:03:53] Speaker A: Generally speaking, they want to know is our API, do we know where they are? So if we have an application and it is exposed outside of our organization, has that got security around it? Do we know exactly where it is? If you're building an application, first we want to know where it is and then secondly, we want to know if. [00:04:12] Speaker B: It'S secured and do people know where they are, would you say? [00:04:16] Speaker A: I would say that there is a lot of work and effort that goes into finding absolutely every API that an organization has. And there is that focus from all levels of the organization now to make sure that they have coverage of those. And I think that say, for example, in banking and finance, they've been doing this for a very long time, so they've got a really good handle on where applications are, what they're doing, what their security is. There's a lot at risk for those. And then I think there's organizations that are coming to this later and saying, okay, well, now that we've got applications out there, do we have that same level of security? And it goes back to every time you're talking about security, whether it's physical, whether it's application or it's virtual, is that the lowest one is the one that is the easiest to target. So almost everybody has to have the same level of security to make sure that they're not exposed. You know, they're not being breached. [00:05:11] Speaker B: So when you say same level of security, how do you sort of, well, I mean how as in a client, how do they sort of know, like how do you get a good barometer on that from your perspective? [00:05:21] Speaker A: So that's a good question. It comes back down to the level of applications and the amount of applications that you've got exposed that, you know, could be interacting with, you know, external parties. So if you've got very few, it's much easier to get those secured. But if you've got a lot, you've got to make sure that you absolutely know where they are and then that requires a lot more work. And so we have customers that have over 1000 APIs, they have those exposed. They would go across multiple silos of the business. Those would be completely different applications that all bubbles up to the top. To be able to say, well, we need to know where all of those are and that kind of audit and discoverability is the key thing. So, but if you have somebody that has a very few amount of applications, then that could be an easier job to be able to make sure that you've got that audit of where those are, what they're doing and how they're getting out there. But then again, you've got to be able to understand what that exposure is. So it has to go from all the way from those small customer base all the way up to the large, but the complexity increases as you go through that. [00:06:25] Speaker B: So what does a small amount sort of look like? [00:06:28] Speaker A: I think a large customer base would have over 1000. So there, you know, they could have multiple thousands of APIs that, you know, would be used for billing, could be for e commerce, could be for customer interaction, a much smaller one might have, you know, maybe one single website and that might have, you know, maybe, you know, ten to 100 APIs that they might have to manage in that perspective. So a smaller business. [00:06:53] Speaker B: So just going around the audit side of things that you mentioned before, would you say people are doing the audit, people are meeting customers and then they're almost surprised that, wow, I didn't know. I sort of had that. Are you seeing that a lot happen post audit? [00:07:08] Speaker A: I think so. I think what I would say now is that in the current business climate that we've got, there is a lot of work going into making sure that people know where APIs are and so making sure that you have visibility of the applications, making sure that they are secured, there's good visibility of those. The problem is that say for example, ones that you don't know or may have been used for as a one off and never been secured or never been clearly articulated or there. I think that's where the fear is within the customer base, is that they need to be able to understand, have we got our arms around everything? Because traditionally if you've got an application, it should be quite easy to be able to understand where those APIs are, where they're going and what they're doing. Those are clearly mapped out. Do we have security around them? Do we know what those are? Where we're spending a lot of time at the moment is around discoverability and making sure that there isn't something that got forgotten about, that person had left and therefore that could still be exposed. Making sure that you've got any of those applications that may even only be in development phase have got security around them as well. And I think that's the place where the fear really is within a bigger organization. Not so much about what they can see, it's what they don't, they can't see. [00:08:24] Speaker B: And that's a good point you raised around the discoverability because I was just going to say, what about when people leave the company? I've worked in a bank myself and like I remember, you know, using certain applications and I was probably the only one using it for the type of role I was doing and then I left. I'm like, whatever happened to that? Who knows is the answer. But it was just more so curious that that's probably the common cause. Someone started there, they've left and then no one knew. They even using a specific application. Is that something that you commonly see? [00:08:51] Speaker A: Yeah, I would say your example there, I can absolutely tell you that in senior security meetings that's the conversation they're having because they do not want to be in a position where that has occurred. Someone has left or there is something exposed that someone doesn't know about. And I think that goes back to the people element of this conversation where you say, you know, the board or senior leadership or the c level come down and they talk to the security team and they say, we want a categoric confirmation that we have no externally exposed APIs that could be breached. And that's a difficult conversation because of what you were just talking about. What happens if somebody left three years ago and that application just been running in the background and now I've actually done an order or had to use it or had any exposure to it. Now you need to go back and find those. And so a lot of the work that we're doing is around discoverability and making sure that those, anything that's external to the organization can be captured. And thats the place where I think a lot of the works being done which then is captured, then you can secure it. But if you didnt know that it was there, you dont know if youre going to secure it or not. [00:09:56] Speaker B: Absolutely. I want to follow this discoverability up a little bit more. Lets use an example. Lets use a bank, for example, as youve been referring to it. Youve got 50,000 plus people. Youve got contractors coming in and out of there. Youve got people, maybe they had a bad experience. Theyre out the door after four weeks. Who knows? So how, how often should you be doing these audits? Because the, the, you know, the velocity of people coming in and out of these organizations, you can't just do it like once a year. So how often should this stuff be running from your perspective? [00:10:26] Speaker A: All the time. It's, it's something that has to be run permanently for exposure across the entire organization. It's discoverability is something that could happen from today to tomorrow. It might be a change within the network that, that hasn't occurred. And so where we see the investment in f five and especially around API security, is about being able to get that first position to be able to discover that. And what that means is that ultimately you've got to do a, you've got to do a checkpoint. There has to be a line and a sand. You have to be able to get to a position where you've gone across the network and found everything that's possible to be found. But then moving forward, if there's any changes or anything has occurred, if that isn't captured at the time that it's happened, it's ultimately a vulnerability and therefore that is exposed and that could be, that could be breached. So it is something that can't be done once a week or once a month or once a year. Effectively, you need to have that coverage all the time. [00:11:23] Speaker B: Yeah. Which makes sense because especially around the example I gave so many people, people starting and stopping and leaving. Who knows what people are up to. [00:11:33] Speaker A: The biggest difference as well is that previously there was that feeling that developers could go rogue or they could just build it, or speed to development was the most important process. What we've seen is that again going back to the people is that there's really strong guardrails now around application development. Anything that you're building out there needs to go through a clear development cycle that also includes security, so it's very difficult to breach. Where previously I think we had seen is that developers were, well, you can't slow me down with security. It's just not important. I think even into the wider business market is that everybody knows that if you do that, you can see what the downstream effects are if you haven't got your application secured. [00:12:18] Speaker B: That's a good point. So when you say downstream impacts, do you think generally people are aware of that? Because perhaps, and I noticed from working in a company myself, you sort of don't. You just feel like a bit of a drop in the ocean. You don't notice those things as much when you're just an analyst, like working against 700 people in a bank example, like in the security department. So do you think people may lose sight of that at times? [00:12:40] Speaker A: In the last twelve months there has been a real driver, that security is everybody's responsibility and where the driver is coming from is that your company's exposure to that is really strong and that is driven from the leadership down to ensure that people are aware of that. And I think that that is where I'm seeing much more of it being driven is that there is such reputational impact to a company that potentially could have a breach, that therefore their focus is all the way through that they want to have those checks and balances all the way down to that developer level. So yes, you might be a contractor that's come in to do some development work that will absolutely get checked for security. They want to make sure that those APIs are not exposed to the wider area and they've got that coverage. That's where I'm seeing the majority of that being driven through. And that has changed. I'm not saying that that's always been the case. I'm not sure how long ago it was that you're in the bank, but I think that there's a real driver within all those organizations to be able to drive that all the way through. [00:13:44] Speaker B: So when you said checked for security, now, in my experience, people don't like being checked. And I think I left the bank in 2016. I started there like 2013 maybe. So that was the common problem we used to have. And again, I know things have evolved since then and we've got proper, you know, security champions and application security etcetera. How do you think people sort of take that whole, oh, well, you know, we're, we're checking you like, without it being, you know, abrasive. But how do you think people take that now? Do you think people are getting better about it? [00:14:14] Speaker A: Well, what I would say adding onto that about automation is that the coverage that when we say checking is that the checking isn't actually done on an individual basis or a individual person. It's as an application goes through the development cycle, there's automated ways to be able to make sure that those exposures are going through, because it just isn't feasible for one person to go through that and look at it. It has to be automated. And what we see is that there's really smart people pulling together those automations for those chicks, making sure that those APIs are not exposed. And then if there is some kind of change or issue with those, then they will get through to a human review. But a lot of these are done just automatically. [00:14:59] Speaker B: So that does make sense. I meant more just from my team perspective, more sort of generating the right comradery between I'm the developer versus I'm the application security person. How does that, is that getting better, would you say, in terms of working closer together? [00:15:13] Speaker A: 100%. I don't think there's that us and them mentality. I think we see that those teams are very tightly connected and it's a single unified voice to ensure that an application can get to market or can get used or can get exposed for either a customer use case or interact with a different application. And so that is very much a, you know, that's. I think that that comradery has been built in as we've gone through this process. It's part of everybody's lexion now. Security has to be part of that. It's not just about developing application as quickly as possible and getting it out there. [00:15:49] Speaker B: So I'm curious now to know, because the whole sort of premise of our interview today is around simplifying API security. So how would you as a company, if someone listening to this, how do they identify if they are approaching API security in a simplified way? [00:16:05] Speaker A: Yes. So I think the biggest thing for us around application security is that f five has always been part of that. And if you look back to five or six years ago, it was very much an on prem position. We talked about that. We knew where the application was. It sat on Prem. That was the place as we went through that. I think that the view was over the last few years is that everything was going to end up in the cloud. And we were going to know exactly where every application was because it was all just going to be in the cloud. What I would say now is that absolutely right now is that there is no one place where an application sits. And I don't see that that's going to change. I think there's going to be an application on Prem. There's going to be an application in the cloud. You're going to outsource the application to potentially a SaaS service to be able to deliver API security around that. The view on that is that how do you uniformly offer every application the same security posture? And so I think that's the position you need to come from. How do you make sure that you've got one offering that allows you to go across every application and it's very easy to manage and that's how you simplify it. Because what we see is that if you've got an application in every single one of those multi clouds, in different clouds, you've got one premium that can be quite difficult to manage all those security postures. [00:17:25] Speaker B: Now, you mentioned before, Jason, you want to be able to get to that position first. Get to that position first, meaning f five s. Does that, do you mean sort of the discoverability perspective? Is that what you mean by that statement? [00:17:36] Speaker A: Being able to get to that position is that you know where all your applications are at, that you know that they're, that you've secured them and that you have visibility of those APIs are exposed outside of the network. The first position that you'd be able to do is be able to make sure that you've ordered all those and be able to understand exactly where those are from. F five, where we sit in that, is that it's very much about making sure that you can see all the APIs, you've captured all of those APIs, you've discovered them, and therefore then you can secure them. So that tends to be the process that we've been through with large customers that have those thousand plus applications. [00:18:17] Speaker B: So going along the lines of simplifying API security, what does it look like for people who have a more rigmarole process? What does that sort of look like from your experience? [00:18:27] Speaker A: Again, it comes down to people, is that if you have siloed business units or you don't have a uniform structure across your entire organization, that is where, that's where the complexity comes in, is that if you have one part of your network say that that's sitting in the cloud and you have a particular security posture in there. But you have a different, more stringent security posture on your on prem solution, then that can lead to exposure to different security problems because you may 1 area may be more exposed, 1 may be less. But is there that uniformity across all of your applications that allows you to then to simplify that? That's where I think that it's making sure that there's somebody at the correct level within an organization, usually the CISO, that the chief information security offer, that sets those policies and ensures that those policies have been implemented. [00:19:21] Speaker B: Yeah, that makes sense. And would you also say that from your perspective or from where you're sitting, majority of companies, and I say majority loosely, would have more of a simplified approach to API security or less so. [00:19:36] Speaker A: I would say so talking about f five specifically here. F five. The customer base that we deal with is banking and finance. These are kind of the areas that we spend, that we have the majority of our customers, banking and finance, telecommunications companies and governments. And so we have a very strong relationship across all three of those, all three of them incredibly exposed to attacks and attack vectors. And they spend a lot of time and investment around security. We spend a lot of time with them working through what those options look like. I think all of them take it incredibly seriously and I dont know, I think the exposure to where we are in the market at this point in time has meant that there has been more reviews on that, but I think its incremental increases. Youre not starting from scratch now. I think that there are certain parts of the market where weve seen that there's been places around critical infrastructure that the government has called out that they go and do those deep dives into, as I said before, is that you look for the low hanging fruit or you look for a place where you can get find someone who hasn't invested as much money in security. What I would say is that the level of work that has gone into the australian market around that has greatly increased and we're seeing a much greater increase in understanding and investment around that. [00:20:57] Speaker B: Now, when you say understanding now, before, I think this other conversation, they weren't, as in APIs weren't really talked about because people didn't really know what they were. Where do you think that understanding is coming from? From the large sort of breaches we've had here in Australia, as well as people like yourself going out, coming on these podcasts, et cetera. Do you think it's that that sort of permeated in the industry for people to understand more around APIs? [00:21:18] Speaker A: I was at acer a couple of weeks ago and the keynotes speaker, their conversation is around app developers and even getting out to that position where the national security coordinator, the new one for the government, Lieutenant General Michelle Guinness, she's saying her second highest priority is making sure that app developers have secure applications. And so this is very much a public facing role. This is about talking about security to, to the general public. And when you're talking about application developers having a secure application and thinking that the general public need to know about that, we're really getting that into the general conversation. People ask all the time about what was f five doing? And now it's very easy to have a conversation about API security. We've seen breaches, people have been impacted. They want to know about that. I think a few years ago it was a don't worry about that. That's somebody else's problem. It's now very much in the public domain. [00:22:18] Speaker B: So I want to switch gears now. And I'm aware, just like yourself, of the macroeconomic headwinds which are forcing customers to be, you know, scrutinize every single dollar spent. So as a result, value needs to be delivered, which makes sense. So how can companies sort of ascertain whether they're getting value or not? What does that look like? [00:22:40] Speaker A: That's a really good question. I think there's a couple of places to look at this. I would say over the last twelve months, and we've been through post COVID, we're now absolutely seeing some economic headwinds, is that in the past twelve months I've probably met with more CFO's in regards to security than I've probably have in the last. And the reason that I say that is that while there is absolutely an impact on dollar spending and where that fits, even at the moving all the way up to the level of the CFO, they do not want to release money unless they know that this is going to have an impact on their business, or that you're ensuring that you're getting value for money through that process. And one of the places I would say is that there's a much greater understanding now for customers that have existing infrastructure, that they're running security within their network, critical vulnerabilities, CVE's as we call them. And what does that mean to their business? Because if they're running something that does have exposure to CVE's and can be exposed, people will be able to exploit that and that could have a bigger impact on them as well. So we find that the level of spending comes back to how much is that going to have an impact on our business and even at the level of cheap financial offers. So they want to know that they're getting their value for money or that they actually need to do this to their own company's benefit. [00:24:01] Speaker B: Yeah, that's a good point. I always look at it like a CFO is about how much money is the business earning and then how much are we burning on products and services? Like, that's fundamentally those are the main sort of things that they're worried about because they're the ones that managing the money. So would you say just generally people in the industry maybe aren't talking in the right discourse to a CFO because at the end of the day, it's like, cool, you know, how many attacks are blocked is all well and good, but that doesn't have as much bearing, perhaps, on a CFO. And I can ask this because I've spoken to a number of CFo's that have actively said, yeah, I don't really care about that. I just care about, or this thing that I'm buying that I don't really know much about, like it's costing money, but is it doing the thing? Yes or no? But would you say that it's hard for someone in that position to really understand whether the thing, meaning a vendor product, for example, is doing, doing what it's supposed to? [00:24:49] Speaker A: I would say, and I say this because I've had these conversations really recently, is that they are really digging into it. And, you know, the CFO, while again, may not be technical, they're incredibly business savvy. And what they need to know is it's about risk versus reward. And so I think there's these conversations that you have where you have exposure to that, any kind of vulnerability, if they understand the level of that issue, they, I have seen them fund things once they go through that process, so they hadn't. So you have to absolutely take them on that journey. And I think that their internal people are doing a great job. They're being able to articulate that. But at the end of the day is those dollars are competing priorities and you've got to make those decisions. The CFO wants to make sure that they're spending their money on something that is critical to keep their business running and making sure that they're secure as well. So I do think that there is a level of upskill that we've seen from that. I also think that that's occurred at the board level as well. Is that the funding that goes into these, they need to understand where that risk is. They have a responsibility for the organization to make sure that they've got those, the security parts to have it off. [00:25:58] Speaker B: I just remember a CFO calling, mate of mine called me a while ago and was like, hey, I'm paying all this money for security. Do you reckon that's too much? And I'm thinking it's a very hard question to answer straight out of the game, but it also, the reason why I'm telling you this story is because it just gave me insight into how they think. They're like, well, that's a lot of money for stuff that I can't physically touch or see. I mean, if you're buying stock, for example, you can actually see the stuff. Security is a little bit hard to see, right? So maybe sometimes they feel like they're paying for all this stuff out of thin air and it's not really there. And also, if they haven't been breached, as we all know, then you're doing your job, right. But again, going back to a CFO perspective, they're just going to probably see it at times. Wow, this is costing a lot of money, more than any other department. Security is not cheap, as we know. So how do you manage those sort of conversations then as well? And educating on someone who isn't a technologist at heart, who doesn't have a lot of experience, exposure to this field. [00:26:52] Speaker A: I could not agree with you more. I think that the reality is that the CFO is getting into that next level of detail because I think you're right. Your friend that is there saying, hey, I think I'm spending a lot of money on it. They are absolutely investing the time to understand where are they spending that money. And look, at the end of the day, the customer is one that makes the decision on that risk profile. And I think more than anything, what we see with the CFO and the organization in general is that it's about risk and they need to understand the risk. And once they understand the risk, they can make a decision from there. It's not a vendor's job or F five's job or a security company's job to make the decision for the customer. They have to make that decision. They have to feel as though they've got all the information to be able to do that. So where I would go back to is that it's really about education and understanding that level of risk. And what I would say is that a couple of years ago, that probably wasn't even there, people would just say, okay, well, look, we've got these budgets, we're spending them. This is where that's going. Because of the competing amount of available expenditure. You have to go through that next level of detail. My experience has been this is that CFO's, once they understand what that value is, that it's been delivered, theyre usually pretty quick at signing it off because they realize they just want to understand what that risk profile is. I think theres also the view that as long as they understand one, what are they getting for their money? But the second part about it is that are they getting any operational efficiencies? And I think that has been harder to articulate. And so that has been a place that weve spent a lot of time making sure that, can you automate this? Is there some way to outsource it? Is the, you know, we know that there's never enough security consultant resources in the market to be able to deliver all that. Is, is there part of that that someone like f five can take on to help those, help those customers reduce down their, you know, their workload? Because it's not about, you're not going to save any money from those security consultants because they're always going to have more work than they can actually do. But if you can push some of that responsibility outside of the organization, that also helps as well. [00:29:01] Speaker B: Okay, I want to flip over now to probably the gen AI space. We'll just talk a little bit on this because everyone still wants to know a lot about it. So maybe let's talk about the potential within AI and Gen AI in terms of being able to predict problems and threats by leveraging analysis of data. This is interesting to me because I was a former reporting analyst and I love data and data manipulation. So what does this sort of look like for, from your point of view, Jason? [00:29:28] Speaker A: Yeah, generative AI is going to be, is a complete game changer. I think there's probably three key areas that are important for us in this, especially for someone like f five. There's one which is just the amount of data that is going to be generated. Because of generated AI is, we've seen so much information that has to go through that. Again, those are via APIs. Those do need to be secured. We're going to increase the amount of traffic that is, that's going to be delivered. So your data that you, that you want to look at is just going to be increased. I don't think we can even guess how many fold, but it's going to be a lot. And so I think that is a, that's a key insight to AI as we get through that. The second one is about being able to identify and collectively help organizations. So where previously they were sitting on their own and they were doing their own analysis or they writing their own policies, I think what we're seeing now is that that will be able to be leveraged because you'll be able to get that collective from the entire world. So somebody is breached in the first person that could be breached for a situation that automatically then can go through to everybody. And I think generative AI will help that from a perspective of stopping breaches earlier because more people know about it. And then I think the last one is that you're going to be able to, this is really a people area and a resource. You're going to be able to help drive that down about how quickly can you get things done. I know that at f five we've got in the coming months, we've got an AI chat bot that's coming out where you'd be able to say, hey, look, I'm AI, I'm just about to release a new application. Can you provide me some firewall options for that? How would you do this? You'll be able to go back and leverage the, you know, the help of what f five has already been doing to deliver applications. [00:31:21] Speaker B: Would you say as well, Jason, people are still a bit rattled by, I feel like I'm asking everyone this question, but when I'm looking at stuff online like LinkedIn and comments, people just still seem rattled by the whole concept. Why do you think that's the case? [00:31:33] Speaker A: I think it's probably one of the greatest things ever. I think the fear that people will have is that there is something that they've missed, you know, as everybody upskills with gender AI and they're able to use that, is that, of course the bad actors on the other side, they can also use it too. So I think that you always go back into that arms race is that you're only as bad as somebody who could use the technology better than you. So I think it's up to everybody to embrace it because it's not going to go away. It's absolutely part of us moving forward and what we need to do is get the benefit for the good people as opposed to handing that over to the bad ones because they will be using that. I think we've seen things like phishing examples where they'll very easily be able to pick that they have moved down very quickly, I think we've seen voice generation have really increased, and so therefore there's got to be better ways that we can address that as well. That is going to continue. If there's a API security flaw that you could, could leverage, that might be very easy to use that globally. If you haven't leveraged that as well, they could pick that up and take that anywhere. [00:32:42] Speaker B: So the other thing I'm curious then to know, around the AI front or Gen AI front, would you say that this will help reduce dollars spent? Going back to my previous question around people sort of looking into stuff more and scrutinizing dollars spent, are you going to see a reduction in that, would you say? [00:33:00] Speaker A: Yes, absolutely. I think that there is a way that we can leverage AI to take out some of those possible mistakes or possible areas where you could take out some of that tough work of building policies that you could very easily just say, this is my application, this is what it's going to do. Could you please tell me the best policies to put in front of that? And that could take immense amounts of workload out of security consultants work time, which would allow them to do, I guess, the heavy lifting, the things that are much harder, that last 5% because you've taken the hard parts out early. [00:33:39] Speaker B: So do you think that reducing dollars spent will be a bit more music to the CFO's ears, would you say, moving forward? [00:33:45] Speaker A: I think that I'd love to be able to say that that's going to reduce down. I think the question would be, is that what we've seen is that there's never enough dollars to go around. And what we tend to see, I've asked this question before of security officers and say, if you had, you know, if I give you an extra million dollars, will that cover off all our security issues? And they would likely say no. So I think what you are always going to find is that is there ever enough money for security? Potentially not. What you want to do is you want to make sure that you covered off the biggest issues, the ones that you can see, the most obvious ones, but there will always be competing areas where they could, you know, they could increase their security posture by if they had more resources or more dollars to be able to do that. [00:34:29] Speaker B: Oh, absolutely. I think that's just human nature. Not enough hours in the day, don't get paid enough by my employer. So, Jason, is there any sort of closing comments or final thoughts you'd like to leave our audience with today? [00:34:39] Speaker A: Applications are going to continue to grow. I think that applications are absolutely being discussed in coffee shops, in boardrooms, not just in the security side of the business. And what we want to be able to do at f five is make sure that those are secured wherever they are, whether they're on Prem, in the cloud, or they're hosted. So for us, it's really about making sure that the application is secured, and we've got that covered. On. [00:35:11] Speaker B: This is KBcast, the voice of cyber. Thanks for tuning in. For more industry leading news and thought provoking articles, visit KBI Media to get access today. This episode is brought to you by Mercsec, your smarter route to security talent Mercsec's executive search has helped enterprise organizations find the right people from around the world since 2012. Their on demand talent acquisition team helps startups and mid sized businesses scale faster and more efficiently. Find out [email protected] today.

Other Episodes