[00:00:00] Speaker A: Security has to become by design rather than something that needs to be taught after the fact. Security has to be interwoven into how the application is being created, developed and pushed and run and exposed. That obviously changes the way security teams have to operate, and that is the only way to address blind spot. Either you're part of the application development process and you have complete oversight of what the application is behaving and exposing how the data is being secured, or you're going to keep having problems and being on the news.
[00:00:34] Speaker B: This is KBCAt as a primary target for ransomware campaigns, security and testing and performance risk and compliance. We can actually automate that, take that data and use it.
Joining me today is Dean Uwari, director of Security technology and Strategy, APJ from Akamai Technologies. And today we're discussing the evolution of the API attack surface. So Dean, thanks for joining all the way from Japan and welcome.
[00:01:03] Speaker A: My pleasure. Good to be with you today.
[00:01:05] Speaker B: So API attacks now in the australian market, there's a lot of this conversation going on. So maybe let's sort of start with your view then on the evolution of the API attack surface. So what does this sort of look like for you, if you wouldn't mind painting a picture for our audience?
[00:01:21] Speaker A: Absolutely.
I've been kind of a bit focusing on the API security topic this past year because as you may know, API security is not exactly a new topic, so to speak, and thus the emphasis on evolution. APIs have been around. It is a building block for application to communicate, and API security has been around for many years. And if you look at the quadrants by Gartner, so they have an API security quadrant, and Akamai has been a leader in that space for a very long time. So it is sometimes a bit confusing on why we have to kind of rehab this API security conversation and why we're hearing by so many attacks in the news. I mean, it is a problem that people think that has already been addressed. Right? But there has been a change, obviously, API themselves that are being used by customers. APIs have also been evolving. There's different kind of APIs. There is soap, there's rest and graphQl, there's new APIs that are coming out. And there is a reason behind that evolution from the API itself.
Since 2019, there has been also a shift in the nature of the application themselves. As 2019, there was this acceleration. It was a kind of a turning point for customers to really migrate to the cloud. I think Covid-19 has been a big catalyst of this with issues with scaling and the ability to have an auto scaling platforms and adopt, either migrate the applications from data center to the cloud, or adopt what we call cloud native or modern applications. The nature of these applications are what is transforming the nature of the attack surface. And this is why we now are trying to address the evolution of the API attack surface and the changing nature of the attacks themselves that the different attackers are adopting that the customers now have to face.
[00:03:19] Speaker B: So I have a question. Well, I have many, but you mentioned before, API security has already been addressed according to people. So why would people just believe it's already been addressed? Where does that come from?
[00:03:31] Speaker A: That's a very good question. Let me put it this way. So API security is, the API itself is how people, a user, let's say customer, because the API is the conduit of communication between machines, essentially API, the definition about an API is allowing two machines or two pieces of codes to is, I think it's fundamental. So essentially, the communication between machine is going to be either the machine that the user is using, the laptop or the phone to interact with the business, ecommerce finance, to do things online. And then you have the communication between the element of the application within the customer environment. So it's very important to have a picture in your head on how that flow is working. So traditionally, up to 2019, what we call the majority of the application used by customers are monolithic in nature, and I'm not sure if you're familiar with that term, is essentially an application role is to provide what we call a front end that is facing the customer or the user, and then you have the back end part of it that essentially is providing the application logic and the data to feed into whatever request that a user needs. Right. But traditionally these applications were monolithic. Meaning is all the elements were within the same block, and there was no need for the front end to talk to the backend within the application. So the sole API use, the sole API activity was essentially between the user and the front end of the application. And thus, obviously that activity, API activity, was happening essentially over the Internet, because users will interact with companies or businesses, whatever service they're trying to access, if they use APIs over the Internet. And that was the attack surface. And thus the solution to secure that attack surface was to put traditionally what we call a WAF, a web application firewall. And our terminals have evolved to including the APIs, essentially with the WAP, with the web application and API protection. Now, that evolution happened essentially because API was not always the main conduit between the user and the front end of the application over the Internet. It was what we call it was mostly application traffic. The API traffic has exploded this past few years and has overtaken the application traffic. But essentially that was the attack surface was over the Internet at the edge between the user, whatever platform the user is using, and the front end of the application, wherever it's hosted, whether it's in data center. So the WAF was pretty much pretty good at securing it at that surface. So it's not a breakdown or kind of like, hey, the attackers just came out with new ways of compromising a WAF. That's not really what happened. Obviously, that's always a concern. But the explosions of attacks that we've seen in the news this past two years, I'm not going to name anyone, but I think it's in the news every day. And it's been affecting every major company in a bad way because people are concerned like aren't you supposed to have API security or security agiper, whatever? And the fact that they are, there's been this obviously emergence of a new way of compromising APIs because of the nature of the evolution of the application themselves. So in 2019, well, that's kind of like a turning point, but I have to start earlier. But essentially, as you may heard, is there is a shift from monolithic application to microservices, because if you move to the cloud or obviously as application become more responsive, more client focused, microservices is ideally suited for those kind of new kind of a service type industry. And what I mean by microservices is using containers or serverless type. But essentially for me that's the right way of looking at why the security, because it's very simple. So now you're going for an application whose primarily API communication was between done at the edge of the Internet, because that's what the user will communicate to the front end, to using microservices, where fundamentally uses API to communicate internally between the front end and the back end. But I mean communities and servers. So I mean, that kind of glares to anyone to see, hey, now I have API end to end between the user all the way to the back end. So there is obviously automatically you go from API, the overall API communication within an user and application is like 10%, it goes down to 100%.
So the question is, is that new API activity secured by the existing security infrastructure, or would there be a need for a new one? And that's basically the conversation that needs to happen.
[00:08:17] Speaker B: So with the conversation that needs to happen, in your role across APJ, are you hearing that people are worried about the security around APIs? Or would you think it's just one of those things that kind of just gets relegated?
[00:08:29] Speaker A: No, I think people are now taking it extremely seriously. I mean, obviously the wake up call was those attacks that we've seen in the news, and they're still happening on a frightening frequency. I know we hear. I think for a while, ransomware has always been a hot tap topic, as you may know, and we're not going to get into that today, but it's been a hot topic. And this API attack just came out of cut people by surprise because. Okay, so now there is another major string of attacks that are not related to ransomware, but essentially that are just as, so customers are taking seriously. And to make matters more important, as you know, governments now have, especially in Australia, which is leading the way into enforcing cybersecurity globally.
Let's just think it's clear in giving recognition to the australian government that have enacted stringent regulation to ensure that customers are doing what is necessary to secure these attack surfaces, but to point it down because people are going, so what is it? Is it API? What do I should focus on as a customer? Is it API? Is it ransomware, is it phishing, whatever, what is it? Essentially, I think there has to be a shift in how you look at security. We cannot look at security as, okay, API versus ransomware. Let me roll the dice and see whatever is going to happen. No, it's essentially what attacker. We have to look at the attacker's mindset. The attackers are after what they're after. Data. Ransomware is an attack after the data, right. Either to steal the data or use it to blackmail you or to lock you out of your data, because that's where the business are driven. Business are driven on data. It is a conduit to data. Like I said, API is what a user allows to get something out of a business application. And the application is all about getting the data back to the client. Whether it's updating your profile on Facebook or accessing a feed or newspaper, that's always data. So API, at the end of the day, data is the name of the game for the attackers. And there is this misconception that attackers are this super, they're smart, but they always enjoy using sophisticated tools and mini screens in front of them and spending nights trying to hack somebody's act, trying to hack somebody's data where that's not really how it works. Attackers are always looking for the easiest way to compromise data because that's the least effort, the least way of them getting caught, because it's a business. It's all about getting data to sell it or to use it. So the less effort you have to put into Nettac, the higher the margin.
There is the new fact today that compromising the API is the easiest attack that can be done by an attacker with the highest return.
[00:11:05] Speaker B: Okay, so you mentioned something there which was quite interesting, which was, yes, people paying attention to it now because of everything that's been happening. So is it going to get to a stage where it's like, oh, okay, well then this type of attack happens. That's why people are going to pay attention to it. Because again, I do see a trend on, yes, people are now focused on it because the thing happened. And unfortunately it has been that way for years. Even going back to breaches over the last five plus years. That's when people start paying attention. But then people can't pay attention to all the 50 things like, well, you can, but you got to prioritize stuff. So how do you think people find that equilibrium? We talk about API security and then let's talk about data privacy. Let's talk about this. Every person that I speak to on this show in their specialization, like yourself, Dean, what you guys all say and ladies say is so important, but then everyone has their own little specialization that's so important. So how does someone prioritize all this stuff? Because there's no way you can prioritize 50 things. You have to look at, okay, what are the top three? And start with that. But then everything. When people start talking to me instead of at length like yourself, I'm like, well, that's really important. We need to focus on that. So how does a leader actually get around that to balancing the whole thing? Because it's quite overwhelming.
[00:12:17] Speaker A: Absolutely. And even for vendors, it has an impact because it's very difficult to have a product conversation to say, hey, we have the magic wand that's going to help you solve these problems.
It's no longer saying, hey, this product versus that product anymore, either even between competitors or even within the same company. To be honest with you, CISos and company leaders also, they're not interested into, hey, okay, do you have the latest? There's just too many products as well that they have to manage and all this stuff. So I think understanding, it's kind of like, hey guys, time to go back to the fundamentals. Okay. I think that's the right approach if you ask me. Meaning is API is not separate from the rest. I look at it as kind of an attack tool chain. It's kind of like, hey, I'm an attacker and I have a tool chain, my disposal, and I'm just going to use. But there are essentially three fundamental areas. It's okay, you have what a customer is exposing to the outside, all right? And essentially that's basically because that's where most of the business now, whether you're government critical infrastructure, finance, everybody's doing business online. Actually, it's a huge difference between now and we can't even say, go back five years ago, perhaps five or ten years ago, not everybody was doing their business online. Critical infrastructure was not necessarily online. There was a lot of stuff was still holed up and keyed up in data centers. There was no concept, well, this ubiquitous use of supply chain. Now it's not just you security, but I have to interact or trust maybe a smaller company that may not have the security or the means to invest in the security that also becomes a threat. So you have to look at the overall pictures. But I can divide it into two areas. Okay, you're securing what you're exposing outside and saying to yourself and moving away from a security strategy, saying, I'm here. My job is to ensure that nobody gets in. And now saying is I'm going to secure the outside perimeter or whatever I'm exposing outside with the assumption that somebody is eventually going to get in. So if that attacker gets in, how do I deal with that in terms of security? So that in itself is what security leaders, whether from our perspective or from customers, are starting to look at as a strategy, rather than say, hey, do I have a firewall or do I have this, or do I have that in terms of product? Because that's not going to help you anymore. What is going to help you in terms of that should be the main topic of discussion when fleshing out security. I think the API is a changing the game because before to breach, essentially attackers had to figure out steal an account. And they still need to do that. In most cases steal, for example, a user account or find ways of exploiting a zero day or vulnerability to get administrator level accounts so that they can get in to get the data or essentially get that data. And that was very difficult for them. And this is why you hear of, and still is today in a lot of occasions. That's why you'll hear of different tools to do that. But essentially what APIs are making things worse is, and I'll explain that quickly to you because it affects everybody's life is attackers do not need to steal accounts anymore. If I want to interact with the bank, all I have to do is get an account online. I can go and create a valid account using my email address and password, and I have access to applications within a business. That's how things works now. So attackers do not need to steal accounts anymore. In a lot of cases, they can basically get a valid account and use that as a mean of the attack. Businesses have to expose the business logic to the user because of the nature of the API. API. Essentially when you interact with a company, you basically have an app that says, okay, these are the services that the company has, whether it's shopping or financial. You do trades online, you upload your feedback. That's the business logic of that company. You want to book seats, you want to book an airline, and there's an API for that. There's an API for that. So you have to expose that to the user so the customers can basically the users and the attackers, by creating a valid account, will know how the business works. And they can now know, see if that is secured properly on the back end, because they will then easily abuse that, or can give you an example in how that can be easily abused. This is why APIs are so scary.
[00:16:26] Speaker B: Do you want to share the example?
[00:16:27] Speaker A: So for example, the most common DPI attack is essentially something we call Bola. Perhaps you've heard of it. So anyway, essentially is you have a user account that is valid because I have an account with the bank or wherever it is. So I don't need to steal those credentials to access my account. Essentially the application will use an API that will say, for example, which is most of the case, using protocol called rest. They use HTTP as a mechanism. I don't want to get too geeky on you, but that's part of the conversation that you cannot hide from the user. So basically I go to my browser, I can easily see the API calls I'm sending because this is not something that can be hidden. You use an API between my phone, my laptop, to the application that is owned by the business. I can see that API call, so I can see what's being sent and essentially typically would look like the version directory endpoint, meaning if it's my account, it's going to be account, my user id.
Those things cannot be hidden, right? I mean, you'll see that from your browser. Now with Bola is essentially saying, okay, the question for the attacker is if I can access my account and the only differentiator is the user id. What if I change the user id to the next one and see if I get a response data? Because if you do, then you've successfully accessed somebody else's account. And that's basically what Bola is, is you do have the right security as a parameter, but the breach is not at the parameter the user is trying to access. Whether authorization of the object, which is essentially representing the data, is done at the back end. And most of the case it is not done because data may be stored in some cloud bucket like x three, or whatever other storage that would have required, perhaps the developers or the user to have configured that authorization on the back end. But because it is a back end from a security perspective, that is not done. And this is why, number one, as you can see, the attack is very easy. It's just a matter of changing a user id using, there was no need to do reconnaissance, I mean, or breach anything or steal anything. This is an API that had to be exposed that you could easily see. It was just a matter of switching the parameters using a command line, your command line, or your browser, and just wait for a response. And if you have a response, then you have access to live data, then you have breached on somebody else's account. That for me should scare the living whatever of anyone that is managing the security for a company.
And the other scary thing is you can't just go on a firewall and say, okay, let me block that. With a rule like the old days, you find a problem, then you create a rule to block it.
It's not something that a rule can block because the attacker is just changing user id. So it's something that needs to be addressed. Hey, go call somebody to put some authorization on the data back, wherever it's stored. That is why this is so complicated and so scary. This is just an example, but I think we can dive into maybe later on, but hopefully this is easy for people to appreciate.
[00:19:39] Speaker B: So maybe I want to switch gears now. Let's swap over to discuss and getting your view on the OwAS API top ten. And because it is an executive podcast, maybe people aren't overly familiar with OWas, but maybe start, just provide the overview and then maybe jump into the top ten. You don't have to go in extreme detail, but just give your view on the ten.
[00:20:00] Speaker A: Actually, the OAS API top ten, without even giving into the detail, essentially is an indicator that things have changed, right? Because there was an OAS top ten for application and API security. It's been there and for many many years. And that was the standard against which people were kind of at least checking whether they have the right strategy in place to secure their application online. But the type of attack, like local file injection and cross site scripting.
But obviously the OS themselves said that was like, wow, there's this new type of attacks that are API related but not covered by the existing top ten in 2019, which coincide with this new, kind of coincide with this evolution of application. They said that was like, hey, we need a new top ten. Which is obviously, if you need another indication, you need to take this seriously or at least look at API security. Again, that is a good indicator. So the OS top ten, actually they've added the word API because obviously it shows that this is actually APIs, though the OS has addressed some of the API compromises, but they had to have one dedicated solely for API vulnerabilities. So I think sometimes in conversation, customers are not aware of it. A lot of customers I've spoken to is either they're not aware or fully appreciate the difference.
Just to boil it out too, is the new top ten is kind of reflect the change of the attacks. Before the attacks were really focused with the OS top ten focused on vulnerabilities like bugs in the software, like zero days that could be exploited at the edge over the Internet versus the API top ten are more focused on the business logic. So it's more kind of related to what we call business logic attacks versus exploiting a specific vulnerability.
And when you look at that, it's actually mainly in three areas, which is essentially compromising the access, compromising the data and compromising the configuration. The security nature of the configuration of your API and access is obviously the majority of the top API. The top ten API. Top ten is actually access related.
Access is not so much access at the perimeter, meaning is, do you have the right authentication authorization for your users? That could be a problem, but essentially is access to the data itself.
There is a reason why that is becoming a hard issue, is because how the data is stored. When you had modeltech application, traditionally the data was mainly stored on the hard drive of the server where the application was run, whether it's a virtual machine or server. But when you start moving to microservices and cloud, modern application, that the majority of the customers are migrating into like containers. And serverless data is no longer stored on a hard drive, it's stored on an external cloud type storage that has its own authentication and its authorization, and where data is kind of represented what we call objects. So that basically because of that shift, a lot of the time the data is not properly secured and the second areas that top tens cover is exposure of data. Now what we mean by that is how APIs share data with customers or users. So traditionally look at it in a way that when you had monolithic application, a lot of the data rendering was done on the back end. Meaning is if I'm in the browser and looking at page and I want to have another, want to see another page that will require certain data, like I want to see my profile or my bank account, the back end of the application will process that page and send it back to the front end to expose to the client. So all the data manipulation was done at the back end and they were not using typically API related protocols like JSON, whatever. They were using traditional protocols like SQL.
So they were not using APIs internally for that. But with microservices, rendering is done on the front end, the closest to the user itself. And hopefully I'm not confusing anyone, but it's important to really look at how application behave to understand a threat. And that shifted meaning is the back end of the application is no longer rendering. The backend now just sends a bunch of raw data to the front end, hoping that the front end will ensure that only the right data is exposed to the customer. Why am I explaining this? Essentially is the APIs are working against you because of the API, the shift in the architecture of the application and the use of APIs within the application. The backend will not always know what the front end wants. It will just say okay, I want to see my profile, I want to see my bank account for example. But the back end will say, well, I don't know exactly. How much do you want to see? Do you want to see just the account balance or do you want to see information about the user, like the user name, address, passport number, driver license number. The back end doesn't know because it's not doing any rendering. You'll just send that raw data back, hoping that the front end will filter out stuff that is sensitive. But then from the application development perspective that's not their job to do security stuff or filtering. They'll say hey, you want that data? I'm going to give it to you. And then the front end will just say the user, oh, you want to see your account? Okay, here's the data. And by the way, there might be a passport number and id number in there. Too bad. And that's what I'm saying. So you can see here the shift in the application inner workings and the shift of APIs within the application is shifting the security posture that you're exposing to your user and thus the rise of these new threats. So the way to solve this is say, hey, adopt your security strategy to this new architectures of modern application, and this is what needs to happen.
[00:25:30] Speaker B: So you said before, you need to understand how an application behaves, which makes sense. So would that then indicate if you don't understand how it behaves, the mechanics? That's where people can run into trouble, blind spots. People feel blindsided when something happens because they don't really understand the biology, if you want to call it that, around how that application behaves.
[00:25:48] Speaker A: That's correct.
It's no longer kind of a black and white. You need to see what the developers are doing. There has to be. Traditionally, there's very little conversation, as you may know, between developer development teams and security teams, or sometimes what they're doing is even outside of the scope of the security oversight. And we're talking now not only when an application is rolled out, but even while it's being coded, we can start getting into DevOps and the supply chain as well. But yes, there has to be security teams and development teams. They need to understand how the application run is the application model ethic, is the application modern and how the application is being coded and rolled out to understand which area of the security needs to be implemented. Absolutely.
[00:26:36] Speaker B: So then maybe just press on that a little bit more in terms of blind spots. Again, with your role, your view, what you're sort of seeing in the market, is there anything else that fundamentally you see that people just skip over this over as a blind spot? Is there anything else that you can talk through that you're commonly seeing?
[00:26:54] Speaker A: I'm not sure if blind spot is the right. Yeah, I understand the blind spot concept, but I think this is really going beyond the blind spot. It has just been adaptation of the security coverage. Number one is appreciating the threat that, okay, this is actually a new threat.
If you really drive to the point, it's like, hey, if the OS form saw the need to create a new top ten, obviously there's something new about the API attack surface. I mean, that's a good indication there was something new. So to the customers benefit, obviously the new top ten was created 2019. So this is not something that was existing before that they just ignored. This is something that is ongoing and it is not going away. But in terms of blastflow, it's going to take a shift on how security is being done. And obviously a tighter partnership between the business and the development team because businesses are pushing developers teams to churn out more application to change code faster. And that could obviously entail when every time you change code, every time you change an application behavior or architecture, you're changing the security posture. And that's basically security has to become by design rather than something that needs to be taught after the fact. That's a new way of doing security has to be interwoven into how the application is being created, developed and pushed and run and exposed. So that obviously changes the way security teams have to operate. And that is the only way to address blind spot. It's the only way to address, hey, I didn't know, or I didn't know this changed, or I didn't know that you're sharing too much data, or I didn't know that this API is doing that. I mean, there can be no kind of like, I didn't know either you're part of the application development process and you have complete oversight of what the application is behaving and what it is exposing, how the data is being secured, or you're going to keep having problems and being on the news.
[00:28:50] Speaker B: Okay, so just going back a step to security by design. Ten years ago, when I got into the space, people talk about security by design, so why is security by design still coming up? So clearly we haven't solved the problem. Yes, you got SeC DevOps and devsecops or whatever you want to call it. There's so many variations to that now, but we're still talking about that. That was ten years ago. That's the part where it makes sense, what you're saying, but we've continuously still, it's like the same conversation on repeat, though. It's like we haven't evolved from that.
[00:29:18] Speaker A: Absolutely. I think you can see security by design is something that is not easy to do and I think it's going to be an ongoing project for as long as we, I think for the next number of years. I don't think that's not going to go away. I think we are making progress.
[00:29:30] Speaker B: But why would it go away though? That's the point, because we keep saying, oh, we got to integrate great security from the get go. How come it won't go away?
[00:29:38] Speaker A: I think it's not going to go away because I think, listen, what I mean by not going away, at least it's going to be implemented. But it doesn't mean that though implemented, the attacks are going to stop. That's why I would rather put it that way, because application will keep evolving, communication protocols will keep changing, and it's always going to introduce new ways for attackers to compromise. But I think though people were talking about security by design, nobody has really took it seriously until this past few years at least. Work up implementing. It's not easy to do. It's something that they need to kind of get control over the developers environments. Typically developers see security as a roadblock rather than something that they need for a long time. So there were kind of a lot of resistance to prevent that friction, because security by design does introduce friction in the development cycle and businesses want to be competitive, you need to churn out application as fast as possible. So number one, the number one thing is the security solution needs to act not as a friction to the development cycle, but as an integral part of it. So a lot of the solutions were not available or are becoming that today. So the concept was understood, the need was understood and appreciated, but the solutions were not quite there yet. But I think now obviously now things are becoming obviously with a lot of the security solution now are becoming easier to integrate with the software development lifecycle and companies are willing to invest to adopt it because they see that, okay, the supply chain is so serious of a risk that I need to take it seriously. I mean, that's basically what is happening now. And also you will see that security by design was also kind of like a topic within the circles of the security teams, perhaps even up to the CISO, but now it's becoming an action item at the board level. So, meaning it's become a threat to your business security, not just a threat to your potential attack. Meaning is that could actually bring your business down, and which will now obviously push companies to seriously invest into security by design, implement processes, because it's not just a product, it's also part of team communication now, forcing the development team to come to the table, to the security team, before even they even architect an application, that's something that was not happening, or sometimes not yet happening. So it's beyond product, it's beyond security. It is also part of people, and I usually call that a layer ten, the OI stack, which is meaning it's dealing with people. Technical, religion and politics has been a factor that's been slowing down the implementation of security by design or making it more complicated, if I may say so.
[00:32:02] Speaker B: So do you think that gap is closing then? Because what you said, yes, makes sense. And obviously it's not going to be always 100% with everything, but just in your experience do you see that gap? If we talk again another ten years on this show, will you still be saying the gap of security by design is still the same level, or do you think over time that'll start to diminish?
[00:32:23] Speaker A: No, I think it's diminishing today. Absolutely diminishing today.
The reason is, like I said, the only way to diminish it is, for example, security teams can do whatever they can go to teams and business organizations to say, hey, you have to force people to be aware of phishing or to be aware of using MFA, or to be aware of security hygiene into how they manipulate company data. So they can't force people to do this. And the only way that's going to happen is if the top business leadership of the company or the governments with citizens enforces it or regulate it. And this is what's happening now. So that's in itself helping implement security by design. It's not easy to do, obviously not at the product level, at the architectural level. And I think this is the challenge that people are going through today. But it is happening. It is happening and I should definitely see it. Meaning is the most basic example that you can use is now, number one, people using code scanners, they're using runtime scanners. There's concept of static application security and runtime application security. Now you have, obviously this API security is coming into the fray, which is no longer just talking about having a WAF API security. It's like, no, I want visibility of every API call. I want to see how the API calls are being done. Looking at the behavior of the API calls, looking at the code committed to the API, that may change the API behavior. So now these tools are allowed to have visibility and to analyze the behavior and how your APIs are being exposed to the rest of the world now are coming into play. So I think security design is happening and hopefully over the next few years will be successfully implemented. But to be fair, we cannot say, okay, that's a silver bullet that's going to address or reduce or eliminate attacks. I don't think that's going to happen, but at least we are in the right direction.
[00:34:09] Speaker B: So, Dean, is there any sort of closing comments or final thoughts you'd like to leave our audience with today?
[00:34:14] Speaker A: I think my closing thoughts is, listen, I think there's a need now to go back to the fundamentals. It's not just how many security products that you have that you're going to stack one on top of the other is going to be going to address or eliminate these attacks, I think, number one, recognize what the attackers are after. They're after the data. The API today are the easiest way to get to the data. Let's just be frank, honest. So there is at least, if you confuse about the amount of regulation, the amount of details within the regulation, because it's overwhelming both from the government and from the attacks on ourselves. And I think from the fact that things get on the news cycle right away and that could be so like the stress around if something happens, my job is on the line, the whole company business is on the line. I think going back to the basics, addressing them is the most important to do. And the basic, what I mean is you need to secure that API attack surface, because it's no longer just a mean to transport data between the user and your application. It's actually exposing your whole business logic. The whole business logic of your company is exposed via APIs now to the rest of the world. Because this is how business needs to be done online. You need to ensure that the user experience, your customer experience, is easy. So number one is, if you want to put the bucket list on how to address securities, secure that business logic, secure your APIs online. Get the visibility on that. Number two is okay. Accept the fact that preventing an attacker, whatever means that Ecker may use to breach your environment 100% is not possible. Eventually somebody will get it, and that's a new reality. So that's the second basic is essentially, yes, you need to protect against phishing and all those things to prevent people to get in, but eventually people will get in. So kind of ensure that your other pillar of security is good visibility on the inside and ensure that if somebody was to get in, prevent that person from abusing the systems internally.
If you don't have those base covered, your API, exposing your business logic and ensuring that you have a plan in place to deal with somebody that has breached your environment. If you don't have those two things, you can keep on going, you can keep on creating strategies, you can keep on adding product. It's not going to help you. Well, at least it's not going to solve the problem. So that would be my recommendation to kind of sit down, look over that and use that as a foundation of your security strategy all over again and then build upon.
[00:36:38] 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 Mercksec, your smarter route to security talent. Mercksec's executive search has helped enterprise organizations find the right people from around the world since 2012. There, on demand talent acquisition team helps startups and midsize businesses scale faster and more efficiently. Find out
[email protected] today.
