Preventing Common Threats With a Holistic Approach to Securing APIs, Software Supply Chains, and App

00:00:05
Speaker 1: Hi everyone. Welcome to our webinar today, which is a combination of several speakers, all of us coming from years of experience with years of experience in the cyber domain. Uh, throughout the discussion will introduce everyone that is talking and explaining his background. Each person will introduce himself just so we know exactly who we have with us. We have Nick coming to us from Salt Security where he is the field CTO. We have Paz with the VP of research at OX security. We have also Oz Avenstein with the vintage investment and myself. I’m a and I’m the VP product at Bright Security and we are going to to start with the several intros about specific areas. Each of the panelists will cover one of the topics that we are covering tonight or today, and then we’ll discuss among ourselves how they fit together. We’ll be more than happy to get your questions as we’re running with the presentation. Feel free to to post your question at the chat. We’ll do our best to answer all the questions throughout this session. From some reason, we will not have enough time to to answer everything that then I’m promised it will get back to you with our, uh, with our thoughts, how we would address the question that was raised. And this is pretty much, you know, the basics. So I will not go over my entire bio. Just say that I’m for around 30 years in the business of software development, tools for developers at cybersecurity work in several companies. And today I’m with bright, and I’ll let each one of our distinguished panelists to say a few words about themselves as they’ll start pitching. And the first one will be Nick from Social Security.

00:02:07
Speaker 2: Great. Thanks, Avishai. Appreciate the introduction. And hello everybody. As was said, my name is Nick Rago. I am the field and part of the product leadership team here with with Salt Security. Be focusing and talking to you today on the security segment of the discussion and coming at you from that perspective. For those unfamiliar with Salt Security, for all intents and purposes, where the pioneers of the security space, we’re a company that offers strategy and technologies that really allows organizations to leverage the the the power of first application architectures and doing that minimal risk. We’re also widely known for our research. We have a ton of metrics and insights that we’ve collected from offensive threat Intel, that we’ve done analysis of trillions of API calls over the last several years. And that analysis has really been the hallmark of reference in the cyber industry as a as it relates to API security. Me quickly, a 25 year, high tech, vet spanning dev testing security, been in the API space for a long, long time. Prior to Salt security, I was one of the original employees at a company called Kong. On the API management side of the world, I’ve helped architect and implement some of the largest API management and digital transformation programs really all over North America. So I’m excited for the opportunity to talk today. Go ahead. If we can just move on to the next one. So a couple of things. We’re it relates to APIs. I’m not going to talk about what an API is today, but I will say this that APIs aren’t just for connecting disparate businesses and applications anymore to one another. They’ve really, really changed the way that we build and deliver applications in the modern age. And we really are in an API first world today. And APIs essentially have become the nervous system that really powers all of today’s digital economy and nearly every aspect of modern web applications and mobile applications that we all rely on. Today. We’re able to innovate an incredible speeds and do it in an incredible, incredible ways with new architectures that are API based. So there’s a lot to love about APIs, please, obviously, but we are not alone in our admiration for APIs. There are lots of other entities that also love our APIs, and for all sorts of different reasons, this has become a very ripe attack surface for adversaries and threat actors. Gartner, in 2022 said, predicted this would be the most active attack surface where we’re going to be seeing a lot of data breaches associated with API attacks. They came back and said that that was actually an understatement in terms of what was actually happening in the wild. So we’re seeing this be an attack surface that threat actors are using to exfiltrate data, take control of critical systems, distrust this, disrupt the business services and supply chains. And we’re seeing it across all different verticals and all different organizations sizes. Today it’s become top of mind API security for a lot of executives. And some of the research that we’ve done, 95% of CISOs in our latest state of Cisco report are saying that their budgeting API security in the next 24 months, and just in our own analytics that we’ve seen from our platform, we’ve seen in the last six months over 400% increase in API attacker activity. So again, this is an attack surface that is, you know, on the move and in up and coming next please Avishai. And you can click click through this just so we get to the three boxes real quickly just as a matter of time. So what this basically means is that with top of mind, we’re still seeing a lot of breaches happening in the wild. And there’s three major reasons for that. There’s a lot of security challenges associated with APIs, and a lot of organizations have to come to grips with the fact that API risk really is an inescapable production reality. And a lot of the reason for that, first and foremost, is related to bad posture governance. A lot of orgs have gone at their digital transformations and modernization projects, and have done it with a lot of without a lot of governance. So we’re seeing a lot of what we call API sprawl in the industry, where organizations just don’t have a good handle on what is even out there from an API standpoint, internally and externally facing what are they doing, what business units and applications are they aligned to, what data is associated with them, who’s using them and how are they using them? Am I in? Am I comfortable with the posture of those APIs? We’re also seeing a lot of organizations trying to use the web defenses that they have in place, on the edge, and in testing to get in front of vulnerabilities and attacks with APIs. And what we’re seeing is that attacks are very, very different from a security standpoint. You still need to do the blocking and tackling of the known bad, bad signatures, bad patterns and behaviors. But APIs have inherent business logic associated with every one of them, and each endpoint related to an application. An individual web application, for example, could have a thousand API endpoints that it uses, each one with its own business logic associated underneath it. If there is a logic flaw associated with it that basically represents a zero day attack surface for an attacker. So if you think about that, if I’m only looking for known bad, there’s a whole heck of a heck of a lot I don’t know from an API logic vulnerability standpoint associated with my APIs. So next please. So what we’re basically seeing out in. In the wild. You can go ahead and build this out. All the way down to the bottom is, you know, where there’s risk, there’s breaches. And I’m not going to go into a lot of detail on a lot of these today, but this is typically the breach categories we’re seeing across APIs today. I don’t know it’s there. So I’m having you know lack of API visibility. Optus was a great example of this breach where an API was actually put out into the wild. Company didn’t know about it. Externally facing had no authentication. Bad posture you know low barrier to breach. And attacker actually took you know tens of millions of records out of that API. We see you know scraping examples with social media abuse and misuse potential. I built an API. It’s doing exactly what it’s supposed to be doing, but didn’t think from an adversary standpoint how can be used business logic flaws? That is still the business. You know, by far the largest attack type that we typically see from a categorization standpoint. I’m inducing some type of negative behavior in the API, something that a developer might have left behind. Sam Curry, last year into this year put the car industry automobile automobile industry on its head when he basically showed he could walk up to a car and if it was XM connected for remote start, look at the Vin number and essentially unlock and take over the car. So again, business logic based on what a developer left behind. And then what we’re seeing right now is social engineering is getting very, very good. Jump cloud MGM Caesars as a first wave of attacks specifically when it comes. We’re seeing a lot when it comes to APIs. If I can get into if I can get into an organization systems or source control repository, if I can get a privileged API. Key attackers are betting on the fact that organizations don’t have what they need to be able to actually detect if somebody has authentication and authorization to an API, if they’re actually in, you know, an adversary, a user of that API. Go ahead, please. So talk to me real quickly just to get to the other speakers, and we can get to the discussion today. But a couple of things. I’ll leave you quick, leave you with quickly, not doom and gloom, the whole presentation. How can we get in front of this first big piece as education? I invite you to go to our website. There’s a whole bunch about security. It’s important to know how APIs are, how APIs are attacked, so I can better understand what you can better understand when you’re being under attack, when you’re being under reconnaissance, and how to get in front of it, and what to do when an attack is occurring. And then obviously last, last slide for me here. And then then I’ll move on to the next speaker. You can go ahead and build this out completely until the right shows up. The other piece is what is a good what is a good strategy for minimizing risk. And it really is. Twofold. One is I need to minimize risk today, and I need to do that in the least less abrasive way as possible. Right, I want to I don’t want to disrupt my ability to innovate for a lot of organizations, that is just starts with getting intelligence. I need to discover what’s out there. How am I, what are what my attack surface looks like, what’s the data associated with them? What business and apps are aligned to it? I need to govern posture and I need to build standardization around posture. If it’s external facing and it handles sensitive data or PCI data, it’s got to use OAuth. Those policies have to be in place and I need to wait ability to assess and govern that. And lastly, I need to know leverage ML and AI and a lot of the great technology that’s out out there today. And I need to be able to discern when someone’s doing bad behaviors against my APIs. Again, because a lot of the behaviors are logic based. You’re not going to know if a logic flaw exist in your APIs. The best way to do that is just look for look for malicious behavior, right? Abnormal behavior that I can actually discern into some type of malicious intent. And the last piece is in the long term side, the right hand side. Working with folks like security and right security, it’s enriching the ecosystem, especially from a salt standpoint. A lot of the intelligence that we pick up around the the APIs inside of an organization, that’s something we want to share with the whole ecosystem, makes you better at testing, makes you better at supply chain security and everything else in the ecosystem. So apologize for talking quickly, but I hope that was a good overview from from an API security standpoint.

00:11:06
Speaker 1: Awesome. Thanks a lot. And now we’ll go to to the next section. And let’s talk for a minute about software supply chain security. And then at the end we’ll try to tie everything together. So all yeah sorry you are the next.

00:11:26
Speaker 3: Hi everybody. So as of which I said my name is Earl Paz. I’m currently the VP of Research at security. And security is a software supply chain security company. And guess this is why I’m talking today about software supply chain and all of that. I’m coming from a network security background. I spent a long time working on the threat intelligence, network security, endpoint security kind of problems. And basically and this is important for today context. I’m coming also from the background of security research, but also from actual product development. So this is very important when talking about software supply chain, because I actually have experience with building software and I know it from both sides. And next slide please be sure. Yeah. So modern software supply chain is, is, is being composed today like a freestyle puzzle or a Lego. Because nobody when you start to build an application, nobody starts with building an OS, not even if you work for a company Mac OS like Microsoft. So you always start with with some kind of baseline of of software technology that is already exist. So a rough estimation is that at least 90%. And guess then this number is actually higher in most cases that the code that you are running is actually not being developed by your own company, but is being borrowed from other open source projects. So basically you get all the heritage of the software bugs and software vulnerability that actually already reside with this open source ecosystem. But software supply chain is built much more than just your source code and the source code of your software dependencies. It’s also all of the SaaS provider that you are using along the way. If it is, for example, for monitoring, monitoring, logging, cloud infrastructure, messaging, anything you might think of, even SaaS security vendors. So we are all part of the software supply chain. As long as we have some kind of relation to the SDLC process. So if you don’t recognize this kind of screen, I guess you are not a developer. Uh, this is a typical npm install command. Basically installing the dependencies for any kind of node project. Now, I remember the first time that I got into a node. It was a on my previous kind of work when I came as a security researcher trying to help a product team to improve the detection, the security, detection of the product. Now I follow the guidelines of how to set up the project. This was my first node project, and then I type the npm install command. And then I thought something must be wrong. I see like there are dozens of vulnerabilities, a lot of critical. And I and I remember I rush to the developers who actually manage this project and ask them what what what’s going on? Why are there so many vulnerabilities? Did you notice? And they said, ah, forget about it. It’s not important. And I said, really, it’s not important. Uh, I’m coming from a security research. If there is a vulnerability, there must be risk. I’m not. I wasn’t really into OpSec back then, but I knew what the vulnerability is. And basically when when I said I’m not going to work on a project with so many vulnerabilities, they said eventually that this is not even their own vulnerabilities. The vulnerabilities are actually coming from an infra infrastructure team, which they are, and they are not controlling their code, so there’s nothing to do about it. So basically a next slide please. So this is like a known secret. Everybody knows it. Nobody cares. Especially not developers. Everybody know this kind of point of this a message by a by the npm package manager. And it’s been existing for, for about six, seven years since the starting to output these kind of vulnerabilities. Next slide please. Uh, but in the software supply chain, they are much more than just open source vulnerable packages or malicious packages. And here I want to take you through a classical supply chain attack, which is the code curve, which happened, uh, about two and a half years ago. So what happened basically that they publish, uh, open source Docker image to the Docker Hub, and it contained a secret. And this secret was of their CDN, which allows, uh, attackers to, to actually modify their, uh, one of their utility, which they publish to their customers. Now what it’s allowed to the, the one line that the attacker added to the to the utility was sending all of the customer’s environment variables, which is basically deployed in the CI, CD, send it to a remote location. So this is basically an explanation of any kind of software supply chain attack. Now what makes it even even worse? So, uh, is that now if there are like, secrets in the, in the, in the code of the code of customers, this can be leveraged to another software. So software supply chain attack. And we actually witnessed kind of kind of those attacks where it was a double or triple software supply chain attack when the attacker actually compromised one company and eventually got to, uh, got a access to a customer of a customer of that company. Next slide please. So there’s a lot of a lot of information out there. Every day there are more and more. And next slide please. And. And this is a lot of information and nobody can actually cover all of this. Next slide please. And so this is why we create. We created and maintained the Oscar, which is a open source software supply chain attack reference. It’s very, very similar by design to the attack matrix, but it’s very, very dedicated on on the software supply chain attack ecosystem. And I welcome you to visit it@pebble.dev and maybe even become a contributor. This is an open source project. Next slide please. And with that I will wrap up that in cocoa. So this is only one kind of attack. And there are dozens of such attacks every year. So one of the one of the things that we have in dev when we present Oscar is also like campaign view, where you can actually see detailed details very, very symmetric about each campaign that we track with the techniques and the effects. Also on the on the target, the initial target itself in this case. In this case it was cocoa and also of its customers. And I’m done for now. Thank you.

00:19:52
Speaker 1: Okay, cool. Thank you all. And to wrap up the complete story of everything together, we have AWS that will talk with us about application security of yours.

00:20:05
Speaker 4: Thank you. Thank you. So hi everyone. My name is Oz and I’m a long time application security architect and engineer. In the past three years, I’ve also been serving as a CSO, but did set up application security for companies such as Fiverr and Tel Aviv Stock Exchange. I’m also a part of the Israeli Board of OWASp, and I’ve been doing advisory board for several application security startups, and I’m here to talk about application security programs in general, because think both Nick and Eyal spoke about very important subjects that think in the past 3 or 4 years, we’ve been encountering more and more and seeing the trouble is that these have been causing and wanted to give some, maybe a more broad a view and touch a little bit about dust at the end, because I am an advisory board member at Bright. So if you can go ahead with the slide, please. So in my personal experience, I see that a lot of organizations are trying to counter application security with a lot of patches without having like a tool program of application security that is built, meaning they will start to do penetration testing, maybe incorporate some tool, but they never build a an approach that allows them to first have a really broad approach that enables them to progress with the organizations scaling up of applications and development, and also doesn’t allow the things that are incorporated even to, to be measured. And I think that one of the things that I see the most is that R&D commitment is so important. And when you’re building a security program and you’re able to take a top down approach, you’re able to get much more consistent and, uh, good results to your organization. So beyond taking a top down approach. Another thing that is important is, of course, to incorporate training and awareness continuously. We will never get on the barrier of having a few abstract architects or abstract engineers comparing to the amounts of people that we have in R&D. So having these security champions within R&D and training our developers to extend security is so important because it’s something that when scaling up, even when I look at an organization that really have a mature application security program built in the organization, the developers are just part of it. And also DevOps. Today, of course, because we have the whole methodology around dev, which I’ll touch in a little bit. But again, this is supposed to be your extension when you’re building an application security program. That’s why really are incorporating given training and awareness session and tools is very important. The third thing is choosing your toolset and I’ll speak about it in the next slide. But there are so many tools today and we’re not sure that we need everything. And last but definitely not least, is that the incorporation of tools to pipelines can definitely help with coverage, with visibility, with the collection of artifacts, and generally work within flows that are more, let’s say, suiting to the agile development processes that we have nowadays in organizations. Can we go ahead to the next slide? Okay, thanks. So in the past couple of years. So I’ve myself been doing this for a long time. And the guys that are with me here on the session as well, we had an uptick. Boom. We had many tools and many companies popping and trying to come out with all these tools. So today, if we look at it from planning and designing to actually monitoring the application, the whole stages that I show here in the little picture we have, we have so many tools that we can incorporate. We have both for vulnerabilities and for malware. Actually, there are some ideas that can give you visibility into malware that is incorporated in code. We have Sast, we have dust. We used to have is and some sort of rest. We have security we have. And at the end we have Pitti like is also a new set of tools which allows you to just have some runtime visibility. And the question comes like, do we need all these tools? So from what I’ve seen, in order to really achieve security, you don’t need everything, but you need to find what suits the organization. And I think both al and Nick gave great examples because. Many organizations incorporate a lot of open source code. And many organizations have many APIs. So these will probably need a supply chain tool. And other organizations definitely need APIs, security tools, but you need to find the toolset that works for you because today servers and free so and find that the cost benefit analysis is so important. You don’t need everything. Everything is a mess. So so tools are usually not optimized tool, and the spoil of tools within the organization can cause more mess than it can be effective. So this is the first the first thing and the second thing is having interoperability and also usability, interoperability between tools and having a consistent view of what we’re doing between all these tools is the thing that will enable you to have metrics. Eventually you want R&D to work with you, and you want your sister as an engineer and architect. You want the system to understand what you’re doing. So you have to measure your work and the measurability and the availability. The ability to show what you’re doing in the organization is so important. So the interoperability between tools, having them work with one another, and to understand the context of their findings and the coverage of the findings is super important. Um, can we go to the next slide, please? Yeah. So I want to touch in short about penetration testing. So penetration testing is eventually the last thing that you need to incorporate in a successful program. And it is required by many regulations and compliance frameworks. And most of us are familiar with it. And it serves as the last point for in order to derive assurance to something that was already developed. And it is the last part that we find vulnerabilities. Usually what happens in penetration testing, as someone myself that has been doing it for a long time is that penetration testing is scoped to a certain frame of hours, and penetration testing will find some critical vulnerabilities, and as soon as the testers will find these critical and high vulnerabilities, they will start looking for low hanging fruit and medium findings. So it will not be that effective. And this is what we can we go a bit forward. And this is where we see dust really incorporates, because I don’t think that we will eventually completely eliminate. Well, we never know now with AI, right? Everything can happen. But pity is something that has been performed for years and is required as it is seen as something manual performed by a tester, which is qualified to test an application from a gray hat or black hat perspective. And what we are trying to build in our dust is first and foremost reduce the scope that is required because so much money is wasted on PPE. I see many organizations that are having the same findings. In 80% of the reports, in 70% of the report is just the same findings. And none of these are actually really like the item that they ordered the pity for. Right. So dust can definitely assist with finding a lot of vulnerabilities and to narrow down penetration testing scope and to make it much more focused. The second thing that it can be automated. You can perform many tests, you can perform it in your pipeline, and you can actually work through vulnerabilities before they get into production or testing. So you can fine tune your development and fixing process. Another thing that you can understand cover coverage better. Understanding coverage is super important. You need to know what you want to test instead of every time performing a pity on the whole application. If you have a dust, you can most certainly understand what has been covered already and what should be covered by pity only by completion. And the last thing is matrix. It’s very hard to reduce matrix by only receiving a test report, right? It means that the second engineer, the architect, need to do a lot of manual work, and having a goal and having a dashboard for these type of vulnerabilities can definitely assist in an enterprise scale of visibility to see what was actually found in penetration testing. So that was me. We show it to you.

00:29:25
Speaker 1: And then started talking without getting out of duty. Will not work as expected. So, uh, thanks everyone. First for for enlightening and putting the spotlight on some of this interesting part. Now, you know, at the end, we need to look at the comprehensive or the holistic environment and understand what’s going on there. And are we secure or we are not properly secured and wealth is such as well. So so of course, we can understand that the each one of the topics that we just discussed at the end, they are combining each other. And in order to provide a comprehensive security solution, you need to deal with each one of them. Now, from from from your experience, uh, how often in the you know, when we’re talking about supply chain, there are different ways of of integrating different things. Whether you are taking specific codes and library into your application, you are just calling an external service through an API. Where are the most common failure point from security point of view when we are talking about, uh, supply chain combinations?

00:30:36
Speaker 3: So I think the the weakest, the weakest, uh, chain or apart in the software supply chain. And I hope there is no many, not many developers in the crowd, but I think they are the weakest link in the chain. And this because they care less about the they they don’t give a damn about security. Sorry about my language. It’s just that if they have a problem, they want it to be solved then. So they look it up in Google and they see in the first answer in StackOverflow, which might not be even the right answer. They see, oh, there’s this open source package which actually solve my problem. Amazing, which is three stars on GitHub. It must be good. And and not getting into even that. The stars could be forged and the amount of stars doesn’t even have to reflect reality and they are just installing it now. They don’t have in mind that this might have a backdoor embedded. It might open like if like installing malware, it’s. And for the for the threat actors, it’s like a it’s like taking a candy from a baby. It’s too simple. So in the in the past, in the past three years, this attack threat actors which actually got a a their life become harder as endpoint security become better and network security become better. But OpSec and especially the software supply chain and same goes for API security. Those still became like the easy targets. And this is why we for these areas we see like a switch for many threat actors, especially like those from North Korea, we see them targeting like what? What is easy and developers are easy.

00:32:44
Speaker 1: Yeah.

00:32:45
Speaker 2: It makes a lot of sense. And, you know, as the next developer, I must admit that in the early days when I was a junior developer or a young developer, everybody taught me that I need to provide working software as fast as possible out there. Nobody ever told me that you need to consider the other things now, with the years, I learned my lesson. But it’s true that you are getting out of college, out of university, and the first thing that you are looking, how do I solve this issue in the most efficient and and best way? Now, Nick, how from your perspective on the world and as you guys are monitoring in runtime, how does it look when there are different items in the supply chain and connecting each other with the APIs?

00:33:30
Speaker 3: Yeah, there’s a couple of things there, and I’ll just echo what you said. Obviously, some of the transformation projects I’ve been in, I’ve seen developers be told you have to develop ten microservices. I’m giving you 45 days to do it. Then you have to move on to the next segment and there and there they’re compensated on getting those microservices done, and they will get them done to a point as fast as they can, and they’ll leverage anything that they can to get them done. Now all of that falls into the application. And one of the interesting things about one of the interesting things about APIs has been when we’ve kind of transformed these apps. Alyssa Knight, who is a well known hacker, coined the phrase that the the castle has left the moat right. A lot of the functions that used to be in backend code are now exposed as endpoints in microservices, and that’s what attackers are hitting at here. And the interesting thing is, behind a lot of those microservices can be some embedded software or some type, some type of software that was embedded in the upstream move. It was a great example of that. That particular breach, right, where 1000 organizations were hit, I forget how many how many records, some 60 plus million records I think was related to that. But again, the attackers are just figuring out if can poke and prod and find something that’s underneath the surface, something that a developer may have overlooked then or is just taking. I think the interesting thing is when developers leverage third party resources and libraries, especially from a logic standpoint and logic flow standpoint, they are assuming that everything that third party developer did was on the up and up. You’re assuming that from a security standpoint, that code is non flawed and that that’s a dangerous assumption, especially from a lot of the attack types that we’ve seen today. And I think the other interesting thing that we see, not just sort of embedded upstream in the supply chain with software, is, you know, there’s a sort of the technology supply chains that we’ve seen, you know, Jump Cloud was a great example of that, and that some of the, you know, if I’m leveraging a third party service in my supply chain as part of my applications or my delivery of my company or my services, I’m assuming that they’re doing everything they’re supposed to be doing from an API security standpoint as well. That was a great example of an attacker figured out, you know, it was the nation state attacker, you know, great social media phishing attack. Got in. Get access to privileged API keys. Now I’m going to try to, you know, lower the, you know, lower the barriers and barriers on the on the actual organization targets that I want to hit. So it answer your question. It it plays heavily in this. So from our perspective just real quickly, it’s all a matter of first just getting the awareness to know what is my, you know, what are the APIs out there and what are they actually doing. So that I at least I have awareness of what that attack surface looks like? The last thing I want to know about is that I didn’t know that API was there, and I’m finding out about it because I’m getting a ransom demand on the, you know, on the dark web saying that I need to come up with some money or we’re going to release records. So. Does that make sense?

00:36:29
Speaker 1: Completely and completely. And, you know, one of the things that I see a lot of times happening, okay, so as a developer, you found some kind of a library or you’re using some kind of a service through an API. Now the vendor is updating his code every he is progressing. The code is not static when you are calling a service for an API. Now, now, now all. What can we do in order to make sure that that okay, I connect it to stripe or to any other services established as an example. Not that I’m talking about any bridges over there, but what can we do in order to ensure that that they are not changing the code beneath our legs and the new malicious things are into our environment?

00:37:17
Speaker 4: Yeah. So insuring is a big, big work in building security. Um, I’ll start off by rail. Yeah. The holy grail is ensuring. I’ll start off by saying that. And I want to refer to you to the first question that you asked in both of the guys and said as well, is that we must always bear in mind that the KPIs from security teams and R&D teams are completely different. So from my perspective in the perspective, R&D is always measured today by exactly two factors time to production and quality of code. And quality of code does not always incorporate security in many organizations, right? It can include many other things, but in many organizations doesn’t include security. So while security is KPIs are completely different, right. Detect as many as vulnerable is impossible and having a good coverage of security in different aspects. So it will always be something that is interfering with one another. And we need to know how to incorporate security to developers in a way that is consumable. So to your question, raising awareness first and foremost, definitely on what is sensitive and what is not sensitive. And from my experience, one of the best ways to do that, because you have a limited workforce in application security is if you’re an abstract engineer or architect and you have, let’s say, 3 or 4 development teams that you are working with, just have an understanding on what they are going to develop. Always incorporate yourself in the product. Uh. Um, sprints, understand what they are going to develop and where you need to work with them on some threat model, because you won’t be able to be in everything. You need to find where you can incorporate yourself, and you need to work with the teams to understand where they need to, when they need to reach out to you, for example, if they’re going to incorporate stripe. So it’s definitely a sensitive case that they’ll need to call out to you. So having this maybe even a little division between where obstacles incorporated and when it is when it is not incorporated is highly important because you need to understand, like the personal aspect of the actual application security architect that is coming in to work towards a on a threat model and trying to detect vulnerabilities and what can possibly go wrong as early, as early as possible is not always available.

00:39:41
Speaker 1: Yeah, definitely makes a lot of sense. Guys in the audience. First, thanks for the question that you have already asked in in the chat. And in a minute we’ll try to answer some of them. And you’re more than welcome to continue and ask us questions. In a minute. We’ll get into the Q&A and then we’ll we’ll get our expert opinion on where on the specific question that you have asked, I want to put another to bring another topic into the discussions. And this is about, you know, what’s going on down, down the road. So on one hand, we need to remember that enterprises in different line of business there are the compliance, whether it is about credit card with GDPR, about personal data. And and this is, you know, breaking the regulation. The different organizations are treating it differently. In some cases, they have a real compliance office that is dealing with it. In most cases, compliances like that is falling under the security. Now you need to remember that if you are using external APIs or application or or, you know, a kind of a supply chain thing, if your supply chain code is breaking one of these regulations, you are liable for that and you are breaking it. So we need to take this into account as we are looking forward. And you know, when we are looking, you know, Gartner keeps telling us what are the future trends and where we are heading. And, and, you know, and some of the more common things that we see recently is the rise of the DevSecOps, how to really incorporate or have security baked into the process of releasing code and different and new capabilities out there, whether it is the excessive usage of of AI today when it fits and when it doesn’t fit, sometimes you see really bizarre thing and you need to remember that I can be an open attack vector. There is already an ASP top ten for for for threat kind of attacks, and there are some tests which are hilarious when you are doing them. This is it will go back in our library. You will see our CTO talking about them. And and there are many things, you know that you need managing the supply risk. Now guys, from your perspective, what are the the the riskiest trends, the new trends that we see out there from what we are seeing from our angle? Nick, let’s start with you this time.

00:42:13
Speaker 2: For me, it’s still the lack of governance. I’m still amazed that a lot of organizations are developing, still developing, without a corporate standard in place, without a security standard in place, and they’re trying to address it and assess it way too late in the development process. And then they’re backpedaling. I think that is a you know, that is a dangerous trend that seems to be spiraling the wrong way, that we’re trying to help organizations get in front of that. You know, we need to be able to, you know, you don’t let hospitals into you don’t let patients into a hospital that a hospital that, you know, is built without a blueprint. Right? So we want to do the same with our data and everything that we’re developing as well. But again, that’s just still a dangerous trend that we’re seeing, you know, taking place right now.

00:42:58
Speaker 1: It makes a lot of sense. What do you think is the most. Threatening friend.

00:43:08
Speaker 4: Yeah, I’d like to highlight what Nick said. So it’s so funny that we had such an absolute boom of tools and we see all of a sudden like are like, oh my God, I need SAS Das security. And they’re like forgetting about the fundamentals that they need to do everything in a top down approach. They need to understand first and foremost that they need policies are in place and they need like a program in order to frame everything and not just being shocked and start to on board tools, because the lack of governance and understanding what you’re doing is, is just an approach that is not scalable. But if you want to talk specific technically, I see that the different points here that are super interesting and I see the hype. But personally, as someone that still sees a lot of Pentesting reports and still work with a lot of fantasy teams, I think it’s something that is also visible on the on the open bug bounty platform. If you go on hacker one and on background, you’ll be able to see that probably the most dominant vulnerability that is still detected is idle and think we had a generation of monolithic applications that were developed in when Python and Ruby were like, uh, like the trend. And a lot of the platform services that are responsible to authentication authorization were incorporated in this monolithic application. And as soon as we had the boom of microservices six, seven years ago, the Docker came in and everybody started to use Docker. Now there are like services that were built in the same organizations but with microservices. And this decoupling led to a lot of idols. You have the platform layer that is supposed to expose like authentication. Authorization remains in the monolithic application. While you have microservices that are not aware of the context that is being passed to them within tokens, then you get to see a lot of idols and you see it just continuing to be like the most dominant vulnerability that is also the easiest to detect for a lot of penetration testers. So for me, you can feel the trend.

00:45:15
Speaker 1: Okay, cool. Yeah, it makes a lot of sense that’s there. For those of you who are not familiar with it is the idea is that you have different objects in your in your system. You are authenticated and you have the right to work with one of them, and you don’t necessarily have to the other object, then nobody is validating that it comes together. It’s a very simplified kind of explanation. If you want to learn more, go to our org. It’s written there in a very clear way. Uh, yeah. What are the trends that you see in the in the supply chain world? What are the dominant trends that are going there?

00:45:50
Speaker 3: So there’s a couple, but I want to. I don’t have an example to go in depth for many, so I will focus on one, which is the role where where we see that in some organizations there’s a lot of SaaS services that are in use, which are like shadow IT kind of services where where nobody really knows about it other than like one software team or group. And consider, like the previous example that I’ve mentioned with code coverage. Now this is a SaaS tool which was compromised and the compromise last for over two months where attackers had full access to to environment variable secrets of the CI CD pipeline. Now, now adding a more one more factor into this equation that even following the breach, was announced and remediated by Codecov. The tokens are still out there. Now consider an organization that doesn’t even recognize that it was breached. So the the effect that this organization is going to have is infinite basically. And and we see we we see even worst kind of stuff. For example, earlier this year there was a breach of circleci. Now I know for colleagues that they it was find out that in their own organizations they are using Circleci. But again it’s a shared infrastructure. So we see this happening over and over again. So even the inventory discovery of which software assets the organizations have, which SaaS applications they have, which, uh, which software they have, I see it all as a part of the software supply chain, because maybe organization is not going to be compromised because it’s so well guarded, but other organization, you have no idea if they are going to be compromised. And I think today if I was a this, this is basically what was keeping me awake at night.

00:48:10
Speaker 2: And then all.

00:48:10
Speaker 1: Of a sudden. Yeah.

00:48:12
Speaker 2: I was gonna say, I don’t think. And then for my answer, I apologize. I don’t think actually answered your question from a technology standpoint. Now that think about it. Um. Just circling back to what Oz said, just to kind of bookend some of my thoughts earlier. What we’re seeing right now, even on the side of it, is a lot of organizations have already started to move to generative AI code generation. Right? And so API’s basically getting a specification of an API, a design using AI to actually generate code for you, and then using that code, and that’s moving into pipelines right now. And again, to Ozzie’s point earlier. We’re just setting ourselves up for a lot of failure and pain. If we do not have governance and standardisation, I need to tell the LM what’s good and what’s bad before I generate code. And right now, unfortunately, a lot of organizations or some organizations we’re seeing start to jump on this trend without that in place. And I just think that’s going to be a whole heck of a lot of, of pain in the future. And then and then to your point, one of the things on the side that we’re seeing is former life worked with regional banks. And one of the problems, and even related to what you said earlier in my supply chain, doesn’t matter if I’m not the one connecting pipes as part of that supply chain. If the data is flowing through, it is related to me. I’m still responsible for it. So we’re seeing a lot of organizations move and move to more complex, complex architectures where they’re forcing a lot of their supply chain partners to go through an API gateway that they support that they’re managing. So even if I’m a if I’m a small bank and I, you know, and I use a supply chain that has, you know, SAS one connects to SAS two, they’re forcing SAS one and SAS two into an API management platform that I can actually see what’s going on there. So I have visibility between the SAS companies themselves. So I just thought that was interesting because that’s something that we’re seeing. It’s adding complexity. But organizations are afraid. They’re saying, yeah, I’m responsible for this data from a regulatory standpoint. I need to be in I need to have some visibility to the flow.

00:50:09
Speaker 1: Yeah, it makes a lot of sense. And yeah, it’s indeed something that we are seeing across the board as well. I wanted to to ask one of the questions that they see came up more than once in the chat is asking each one of you what is the most common types of attacks that you are seeing out there? So Ida was already on the table. But guys, what are the most common things that you are seeing? Nick? What’s going on in the API? What is the most common today.

00:50:37
Speaker 2: That’s still on the world? OWASp top ten calls Bola an object level authorization. Still by far the number one attack type that we’re typically seeing. Folks that are trying to find logic flaws to induce some negative behavior, behavior that gives you access to somebody else’s data up and coming attacks have to do with, I would say, two quick ones. One is related to social engineering. We’re seeing that all over the place right now. I’m trying to get access to your source code repository to find some static API key, because once I have that and I have authentication authorization, you you inherently trust me. So unless you can behaviorally detect that I’m abusing your API, you know you’re none the wiser. So that’s that’s another one that we are actually seeing in the other one that’s coming up, up and coming right now is low traffic denial of service attacks. If I can find again, if I’m organizations are exposing a lot of endpoints out there today, like I mentioned, a web app, one web app itself could have a thousand plus endpoints associated with the function of that application. If I can find one endpoint that’s that’s important in a call chain or a workflow chain that I can induce some type of negative behavior that will take a lot of compute on the back end or log, you know, lag response times. Now, I don’t need a lot of traffic to take down a system or a service. It’s a little amount of traffic focused on a, on a few amount of endpoints that can induce a negative behavior of. And we’re seeing that become more and more productive because it’s getting through the traditional defenses right now that people are typically looking for denial of service detection. Yeah.

00:52:06
Speaker 1: Just ask for a report ten times for millions of records, and you kill the system if it is exposed and from your side. What are the most common attacks that you guys are seeing? Yeah.

00:52:20
Speaker 3: So basically so our product is actually is a from the left part of the of the of the map. But I will address attacks that I’m because I used to be on the right side. So I keep monitoring our own access logs. So I see actually the attacks on our own systems all the time. And I must say that the attack haven’t really changed. Like the massive the massive wave of attacks haven’t really changed in the past several years, which we see. We still think like people still trying to attempt for log force and simple path traversal and SQL injection injections, because it’s simple. So basically my point is that there’s a lot of complicated and advanced kind of stuff. But but mostly the attackers are still running boards. And if you are not covering yourself against the basic stuff like they always top ten, then you are in real trouble. So starting with this kind of baseline, having this first line of defense, deploying a good protection, making sure your code is safe. This is always like a first, best practice. And when you are building your ops program.

00:53:36
Speaker 1: Mhm. Thanks. Are there anything to add to that mash.

00:53:40
Speaker 4: Yeah. Want to add to, to what al said and maybe even relate to what OCS are doing is that. Most most of the attackers. Eventually they are on entry level. Most of the attackers are not complex, and what is interesting to see is that supply chain attacks are available for all levels of expertise, and they can be so severe because even organizations like the most protected organizations still have the problem with supply chain. And it’s enough that a script will find this one library that he can tamper that is open source in order to make an impact on a big organization. Right. So think entry entry level attacks can still still affect even the biggest organizations, because even a supply chain attack can, doesn’t really need, in a lot of cases, high technical expertise.

00:54:33
Speaker 1: Yeah, it makes a lot of sense. And I must say that from our perspective, you know, it’s right as we are a dust product and we are testing in the, in the, in pre-production, we are testing the, the applications. We see so many times that the sky is enabled and the tests are failing. Let’s be a lie and success, which are very common things which every developer should know by by now how to handle. And still we see that in pre-production. It’s already failed. And then of course they will appear in production in the runtime. And we do understand that if you are not, if you are thinking that no, this is such a simple attack, nobody will do it. Yes, this is what’s happening at the end. So we are almost up to the time and I want before we are, we are ending this session just to make sure that everybody on this webinar, if you have additional question, if you have additional queries on the different areas, whether it is supply chain or security or security testing and application testing, you have details on the screen how to contact us. All four of us exist in LinkedIn and then in X and in Twitter and uh, which is X, and you’re more than welcome to talk with us and we’ll be happy to continue the discussion as this is what we are doing on a day to day basis. So guys, I want to thank you again, Mikhail, also for joining me today for the session. The recording of this session will be available if you would like to share it with other colleagues that were not able to attend. Today, you will get notification from us and we’re looking forward to continue the discussion with each one of you individually. And if needed, the whole four of us will come to talk with you, with you specifically on your world. So thanks everyone and have a nice day, evening, night, wherever you are. Cheers, everyone.

00:56:35
Speaker 2: Cheers.

00:56:36
Speaker 3: Thanks everybody.

00:56:37
Speaker 4: Thank you guys. It was a pleasure.