Building Application Resilience Amidst Regulatory Shifts

Hi everyone, welcome to our webinar together with Radware today "Building Application Resilience Amidst Regulatory Shifts". My name is Osman Celik and I'm a Research Analyst at KuppingerCole. Together with Prakash Sinha today from Radware we are going to talk about the changing landscape of regulatory compliance and how to deal with it. Let's do some housekeeping first and you are automatically muted so you don't need to do anything with your browser or your Zoom application and the session will be recorded. We will be sharing the recording and also the slide decks with you after the webinar.

After my section and then Prakash's section we are going to have approximately 10 to 20 minute long Q&A session so throughout the webinar you can always send us some questions and I will be presenting them to you everyone at the end. Before we start we actually have one more question for you which I was personally curious about. Which region are you participating to this webinar from and here you have the options. Please choose the respective one and maybe this might be of use at the end of the webinar. If you have any questions, please feel free to ask them in the Q&A section.

Maybe this might be of use at the end of the webinar when we are discussing the poll results. We have another poll question and this is about whether you have already a compliance management solution in place in your organization. This is very easy yes or no.

All right, let's talk about some agenda today. My section will cover what are the trends in the threat landscape and what sort of attacks are prominent at the moment. I mean compared to last years and later on we will be talking about what are the trends in the threat landscape and also in the compliance landscape and afterwards Prakash will make his presentation about the Wildwares cloud security platform solution and then we are going to have a Q&A.

All right, I prepared some cool slides for you thanks to my sources. You'll see that you see that I used some data from third-party sources because it is very tricky to find a data that is showing about 2024 at the moment but these are some solid data that we can discuss at least today. It is very tricky to find a data that is showing about 2024 at the moment but these are some solid data that we can discuss at least today.

When you research what is changing and what is being the most threatful actor and when you want to see the way you want to look at the radars and then also the threat reports, the number one threat is always ransomware and it's just changing like it's just changing the this is just disguising and then coming and popping up every year. It's just one thing I would like to highlight is that this year we see more of the third layer attacks which means like the triple extortions.

So on top of the file encryption and data theft we also see some DDoS attacks and third-party supplier attacks also embedded to this ransomware attacks as the third layer and this is something you guys should keep in mind. And of course with the phishing attacks also becoming very real and then also with the use of AI they create some perfect phishing campaigns and then identity and social engineering attacks are also one of the biggest threats still.

But specific to this year we have also seen lots of elections all around the world not only in United States but also in Europe and also in the critical regions of the world. We have seen elections and also armed conflicts are still ongoing and this is also part of the cyber crimes that we have suffered this year and then we also see their effect. And last but not least of course the generative AI and its effect on the threat landscape which I will discuss later on in detail because we have a specific section for the EU AI Act. And maybe I can also briefly discuss the map.

You see that the United States and Canada and Mexico, North America is still leading the most targeted region followed by Europe and subcontinent of India, Russia and Latin America is followed by that and also Middle East. There's no surprise here and you can also see the breakdown of the verticals here. Technology, telecommunication and financial and then the government public sector is targeted the most. And here I got this quote from cyber security ventures. It's actually a really nice way to illustrate what we are dealing with. In 2015 the total cost of cyber crime was 3 trillion dollars.

A lot, a lot of money but just in 10 years it has become tripled and it's expected to reach 10 trillion dollars next year. And this year it is projected to the round around nine and a half trillion dollars whereas it was eight trillion dollars last year. So these are some numbers that we should be aware of. I think when you think about the five years, ten years projects. So the money that we are going to waste on is going to be enormous. All right. So from here on we can directly dive into what is changing in the regulatory compliance.

We see that the shift is more becoming from reactive to proactive measures and the solutions that are coming with proactive cyber security measures such as attack surface management, HDR, NDR. The solutions that do not really focus on the incident response. And on top of that we also see that there are lots of regulations focusing on AI to mitigate risk arising from there because it's basically the kind of the holy grail at the moment. Everyone is using AI in order to prevent attacks but also trigger attacks.

And for some industries we see some tailored compliance, regulatory compliance adjustments. And we also see a focus on the third-party vendors and supply chain security. And like I said for the tailored specific industries the critical infrastructure sectors are also on target and most compliance is focusing on these sectors at the moment. And on top of that you will see that I will be discussing five, six compliance today. But on top of that we also have some other regional compliances. And one thing I noticed that many of them are actually referring to each other.

And then I see some chance of maybe some someday maybe an international AI law or at least some maybe international or regional laws maybe promoting the same criteria with the articles they are mentioning. And I expect some unification on this. All right. So starting with the first regulation. We should be aware that PCI DSS has been updated from 3.2 to 4.0. And everyone should bear this in mind especially from the sectors that are dealing with the payment card industry. And what is changing in with the 4.0 is now we have more prescriptive controls and a risk-based approach.

And now MFA is required from all the cardholder data environments. And now we have automated log reviews and continuous security monitoring of key updates. And on top of that we also have this vulnerability scans that must be performed via authenticated scanning apps. These are all the changes that I would like to highlight for PCI DSS. But when you are curious what is really changing, I mean this has been a fact since the 1st of April. And if you're really curious you should go and check their website and you will see a list or an Excel list covering all the changes.

It's impossible to highlight everything. These are just the ones that I thought that will be relevant to most of us here. But please go check PCI DSS website to see all the changes that might be relevant to you. There's a huge list of changes. All right. Our second compliance that we want to discuss here is related to our audience from European Union but also relevant to everyone doing business within EU and with EU.

So DORA, Digital Operational Resilience Act has been recently entered into force actually. And then this is going to be mandatory by the early 2025. So we are approaching there in a couple of months. Everyone will be talking about DORA and how to comply with it probably. And I can share you some recent updates related to this. Now the financial institutions should perform resilience testing. And you have to have some improved clarity on the incident reporting timelines and procedures.

And you have to also be careful with the deadlines that you are when you're providing when they are required by the financial institutions and service providers. You have to achieve the full compliance by early 2025. And new protocols introduced for conducting digital resilience testing. All right. Sorry. Yeah. And the third compliance we are going to talk today is NICH2. This is also again going to be a step up from its legacy version. And this has also came into force pretty recently, actually a couple of weeks ago. And here you can see what are the changes between NICH1 and NICH2.

Basically it's the same. It's the same as before. It's the same as before. It's the same as before. And it's the same as before. And it's the same as before. What are the changes between NICH1 and NICH2? Basically it's the NICH2 is covering a broader range of sectors, obviously. And it is giving some more stricter timelines for reporting, especially when you want to prepare your reports. Then you have to be when you are required to complete them in 24 hours. And the detailed one is in 72 hours. This is something you should keep in mind.

And the other one is top management is now affected and hold accountable for compliance with NICH2. And you will see that NICH2 is also bringing requirements for securing the entire supply chain. This is something new as we already discussed. This was also one of the reasons why I highlighted what are the main and prominent threats in 2024. Because supply chain security is becoming very prominent. Moving on to the next one. Here I wanted to also cover something that is already in around for a while.

But FedRAMP is a classical, very important compliance that everyone must know and also be careful with. I will just basically highlight the latest changes. And this is now, I mean, you already know that the three baselines, low, high and moderate security levels on top of the fourth one, the software as a service, low impact software as a service baseline. So we have this four category in FedRAMP, as you know. But FedRAMP has gone through several changes in last one to two years, not necessarily in the recent months.

But this is something to keep in mind that we have FedRAMP and also the European Union regulations are becoming more and more aligned and referencing to each other. So this is something we should keep in mind. And I expect maybe FedRAMP also going to a revamp or at least a couple of updates after, especially NIST 2 and EU AI Act came into force, because they will definitely change the structures of the European companies and how they do business. And this is definitely going to be also reflected in the United States.

Oh, sorry. Moving on to the last compliance that today I wanted to discuss with you is EU AI Act. I hope that most of you have already gone through and checked what this is and how they are relevant to you. But now with the EU AI Act, we have at least something in European Union that regulates AI and use of it. And it basically categorizes the risk into four categories, unacceptable being the highest, high, limited and minimal.

And there are still, as far as I understood when I went through these risk categories, there are still some debates going on how to classify them because of the changing nature of the technology used behind AI. So this category levels will be probably updated in a shorter time than we expect. And one thing, for example, another thing to keep in mind that there are strict penalties for non-compliance, and it can go up to 30 million euros.

Similarly, and then the imposements will be similar to GDPR. Last but not least, it entered into force in the 1st of August, but some of the implementation timeline has been updated. So please go and check the deadlines and the requirements for your company, your organization, and act accordingly as soon as possible. All right. So we have another question now, and it's actually about the last regulation I discussed. Have you heard about the recent enactment of EU AI Act and its potential impact on technology and compliance? Yes or no question.

And as I said, I will be sharing the results at the end, if we have time, and then we can see how relevant these topics we discussed to you, or if it was really useful or not. Before I wrap up, I have a couple of recommendations, let's say, for achieving the best compliance with the changing landscape. So first one is implementing risk-based controls. You should have some security controls already in place, but please make sure that you are risk-oriented and also having a zero-trust mindset.

Please make sure to continuously monitor and report your incidents and make sure that your security teams are aligned. Of course, implement stronger authentication authentication methods, especially for critical systems. Make sure that you have detailed documentation and then ready for the audit trails, because I am sure these regulations I just discussed are not the only regulations that you are obliged to comply with. So make sure that you have your documentation and audit ready. Regularly check your cyber resilience and simulate threats. You can use some tools for this.

For example, I've been recently researching the breach and attack simulation solutions. This is something I would say close to penetration testing, you can take a look at it.

Of course, implement strong third-party vendor management, because this is a very hot topic, as I've been saying, from the recent years and especially from 2024 on, we will see lots of focus on the third-party attacks and then the focus on it. Because now, especially with the enablement of AI, we see many attack vectors reaching to our suppliers in the third, fourth, fifth degree. This is beyond our control, so you have to make sure that you have some third-party vendor management and security measurements. Make sure you have AI transparency and explainability.

Basically, you have to comply with the AI regulations and please provide training to your staff. Make sure that they are up-to-date, they have the up-to-date information and aware of the prominent and the recent attack vectors.

All right, here, I think I'm right on time, Prakash. One minute and please take your time and when you're done, let's have a Q&A session at the end. Sounds good.

All right, hopefully you can see my screen. So, thank you, Osman. That was great coverage of the recent changes that have gone in, especially on the compliance aspects.

So, Radware is a service provider, so not only do we act as an MSSP or managed security service provider, but also we deliver products and so these products help address the network and application, both delivery and security. Specifically, we focus on denial of service protection and application protection and we deliver that through as a managed service and through cloud applications as well as on-prem appliances.

Now, in terms of the changing threat landscape, there's a lot of attack tools that have come in play and these attack tools implement or include some of the AI agents as well. So, the threat is changing rapidly as Osman covered.

Now, in terms of denial of service protection, especially with the new compliance acts that have come in play, especially with FedRAMP and with the EU AI Act and the NIS2, it requires critical systems to be secure, right? So, denial of service protection is one of the key areas to keep some of these services available, especially government services, healthcare, financial services.

It's very, very critical that you have these available. Power sector is another one and there are a lot of attacks, nation-state attacks on these infrastructure.

So, denial of service protection helps you protect and keep these services available from threats. It doesn't matter whether your applications are on-prem or in the cloud, depending on how your business is. Application protection, there are lots of new changes that have gone in with PCI DSS4 and then Adora as well, especially covering data protection as well as API.

So, Osman talked about the client-site security, especially in supply chains. So, if you don't know how supply chains work, typically you have applications that are composed and they're composed of services. It could be microservices, they could be, if you're implementing service-oriented architecture, could be composed of a variety of different services. These services, some of these services could be from a third party.

Now, if you know how VM applications work, typically you have an HTML page that gets loaded and it loads all of these different components together and then makes API calls to each one of them to create your application that you see on your browser. If some part of that infrastructure or API calling to a third party gets hacked, then without you knowing, even though you are providing the application, without you knowing, your application may get hacked.

So, the data can get exfiltrated to somebody who hacked the application or the API or the third party. So, that's the supply chain that needs to be protected.

So, there are lots of client-side tools that can sandbox and make sure that these scripts are secure. And we'll see that in PCI DSS4. That's one of the aspects that PCI DSS4 covers.

And also, if you have applications that are hybrid, meaning on-prem and in the cloud, or just purely in a cloud-native application, you need to know how your storage is secure, how these applications are getting accessed. And Osman just touched about the zero-trust architecture, which is an aspect that you should look at because there is no longer a physical premise.

So, using identity as a perimeter is very critical. So, multi-factor authentication, and there are many different aspects of multi-factor that you should look at. Zero-trust architecture and cloud service access brokers, those are aspects that – those are tools that you should look at. In terms of portfolio, Radware focuses on the application protection, denial of service protection, load balancing, which is another aspect that we are not specifically focusing here. But load balancing is also required for making services available across – and making them resilient.

And this is important in terms of compliance, especially with critical systems. And you'll see that in both in NISTU and FedRAMP.

So, how do you make your services available? And this could be not just services available as an instance in the cloud or on-prem, but also across – if you're a distributed application, making them available across failures, whether one of your cloud services or cloud data centers or physical data centers went out – had an outage, how do you make sure that those services are still available?

So, that's an area that load balancing, also called application delivery controllers, work in. And then, one – if you don't have the infrastructure to make these broad changes, one aspect is using managed services.

So, security is very critical, and there are very few people who really understand it well. Some of these managed services, you can actually outsource some of this, still keeping control over where your data resides and also reporting functionality.

So, those are areas that Radware focuses on. We deliver – we are also a service provider, but we also work with partners to rebrand some of our services. The way we – excuse me – the way we deliver that is through a worldwide scrubbing center. We have 21 so far with very high capacity for mitigation, almost 15 terabits that we do today.

And then, closer to the users, we also have a point of presence for application protection. So, if you – one way to protect, especially in a multi-service composed application, you can't just implement a web application firewall because you don't have control over all the different services that are being used to compose an application.

So, one way to deliver those services and protection for them is through a cloud-based deployment so that you can have risk-based controls that Osman covered. So, those are areas that you should look at, data lakes and information event management systems. They can compose data from a variety of systems and give you insights into what's going on. Since Radware is a managed service provider, some of the best practices that Osman covered, we actually implemented ourselves.

So, in terms of phishing, the security awareness, we run quarterly drills on phishing for our own administrators as well as users that manage some of these security services. We maintain a security posture and variety of tools, not just Radware tools, that we implement to protect data and APIs for our customers.

So, we have many large customers that we host. So, how do you protect them? We also do cloud information event management, so SIEM, different from S-I-E-M.

Also, cloud security posture management or C-S-P-M. We also, even though we don't provide services, but endpoint security, encryption of disks, those are some healthy best practices that you should implement yourself. In terms of compliance and privacy, since we are a service provider, just the PCI report itself, SOC2 reports, GDPR, those are compliance that we implement ourselves. And since we are a service provider, we also provide reports for customers that don't have their own data centers or cloud centers or services if they want to outsource it.

We provide them regular reporting because there are lots of reporting requirements in terms of how much time do you have. So, Osman covered 24 to 72 hours. And in terms of U.S., it's actually you have four days, 96 hours if you have a material event or a breach that you have to provide these reports to SEC or Security and Exchange Commission.

So, basically, you don't have too much time. And like Osman covered, which was the management is now responsible for authorizing and signing off on these and they're materially liable.

So, that's a very big change that is going on in terms of if there is a breach, who's responsible and liable. So, that's a change that has happened.

So, we provide reports for all the different services that we provide in terms of compliance to our customers. We also maintain certifications. And these are important.

So, PCI, ISO, GDPR certification. And then we also have the FedRAMP and GovCloud certifications. And this has specifically to do with some of the risk levels that are in play today.

So, Osman covered that. I'm not going to go in detail. But more specific in terms of PCI DSS Osman talked about a variety of different changes that have gone in with PCI DSS 4. You should visit their site. Very detailed. The key ones that I'm focusing here are specifically requirement of a web application firewall or a web application and API protection. The other is supply chain attacks, right?

So, these are API based attacks, also called business logic attack or BLA. And this is where you have a composite application that's calling a third party services.

So, supply chain attacks. In terms of client side protection, PCI DSS 4 has made some very important changes, especially in terms of risks and also reporting, right?

So, those are two areas that they have made significant changes. And if you look at the section 6.4.3, you have to now confirm that each one of the scripts that are being implemented for securing your PCI infrastructure, you know, you have to maintain the, you know, authorization for that.

So, if there are any changes, it has to be highlighted, especially on the payment card or payment page. You also have to maintain inventory of these scripts and any justification, so this is in terms of reporting, any justification that is required of why that change was necessary. This is also important if there is a breach in, you know, in progress.

So, not only should you get reports on this, but also you should have a detailed level of reporting available for the authorities if you need to actually submit some of these detailed reports. So, the way we implement some of that is in terms of our offering.

So, this is an example application that we created just to show, you know, a variety of different scripts that have gone into this specific application, and it maintains a list of, you know, what's the status of each one of these, are these authorized, unauthorized, are they new, and also threat levels that are associated with some of these scripts, right, and the action that you can take to protect the access to applications, right. So, for example, if there is a change in place, what's the threat level?

So, basically, risk level that Osman talked about is very, very critical because you should have risk-based controls, okay. So, that's an area that we are covering. In terms of section 11.6, we give you a broad overview of, you know, variety of different protections that we provide in terms of application firewall and API protection. It gives you a view of what's happening.

You can, you work through a managed service, security service provider, or implement some of these by creating some of these best practices that Osman covered. So, in terms of juice shop secure here, you know, a sample application, if there are any changes that you're making to a script, for example, it should give you whether it's in plan, so being able to go through some of these scripts, so scanning some of these scripts and being able to tell you if these are able to provide some of these compliance for you.

And then, of course, you know, a list of authorized scripts that are in play and then threat levels associated with that. We also give you a very broad overview on in terms of PCI DSS4, not everything, but the areas that we cover, especially, and it highlights it with the sections that are being covered here, right?

So, you can associate this and broader PCI DSS support for other products that you have, and then you can create a detailed reporting on maybe a monthly or a weekly reporting as a best practice, both for your C-level executives that are responsible for in case of any material incident, but also providing a good overview on what's going on with your implementation of PCI compliance. In terms of reporting, we provide automated reports, so this is important in terms of reporting.

I don't know where the there's something on the screen right now, but, you know, you can get automated reports, and this is important, especially if you want to see how secure your systems are, and then that's one area that is required with PCI DSS4. In terms of NISTU and DORA compliance, so these are critical systems, right?

So, if DORA focuses on financial services, NISTU is more broad in terms of critical infrastructure. So, all the different aspects of availability and security of these critical systems are important.

So, we don't cover everything, of course, but in terms of application and denial-of-service protections of protecting your networks and your applications from both denial-of-service attacks, as well as application attacks, whether they are AI-based attacks. If you haven't seen yet, you should actually go and look at OWASP, O-W-A-S-P, top 10 for LLM application, which is a large language model.

So, these are based on AI-based systems. Look at how you can implement. This is very, very similar to what we used to do with OWASP for API protection and OWASP for top 10 application threats, right?

So, those are areas that we cover both for our systems because we use AI-based implementations for security operations control, so that since there are so many threats and so many attacks in play, how do you look at all of these and make sense of it, right? So, we've implemented some AI systems to narrow it down and give you recommendations of what to implement, right?

So, that's an area that we are actively working on, especially using AI agents to both implement some of these controls, security controls, improve your security posture, but also give you automated reporting and also protect from some of these threat actors that are taking AI into play. And there are lots of tools on GitHub that you can see that allows you to go through, you know, allows hackers to actually attack your applications with ease. They don't even need to know security, right?

So, many, many tools. They use AI poisoning, they use data, and of course, header manipulations like automated header manipulations.

So, there are many different ways of doing that. So, we are implementing, you know, in terms of critical systems, this is how we are implementing a broad range of security and availability aspects that are required for securing critical infrastructure.

So, this is an example. We are focusing on networks, load balancing, access control, some of the rules that are in play, bot systems that can come into, and then, of course, web DDoS, these are new type of attacks that are in play, and also the protecting your client side.

And so, it gives you, you know, a good overview of what's currently in play, what's deployed, and what systems are being protected. You can drill down into some of these and then report on this. This is freely available to anybody. It's a global live threat map of what systems are being attacked, and it gives you information of where the attacks are in play today. You can go to Radware.com and look at a live threat map. You don't need to be a customer of Radware to, you know, look at this.

We can report on events, and you can drill down on some of these events, and of course, there's capability of providing some of these reports to your C-level executives or to management that is responsible for some of these. And, you know, this is just an example of PCI DSS report that you can drill down, and it gives you a variety of different controls that are in play, and you can have an automated weekly reporting if you need to. Osman covered the EU AI Act and the risk categories of EU AI Act. We are focusing on the high-risk category.

This is critical systems, and so the same thing, like in terms of the portfolio we deliver, you know, data protection and privacy, ensuring availability, making sure that the systems are scalable and performant, and then, of course, preventing unauthorized access and data privacy. So, those are areas that we cover in terms of the high-risk systems in EU AI Act, and then, of course, we provide you visibility into some of these.

So, just to wrap up, you know, when you're, you know, Osman had very good best practices. So, what are you looking for?

So, first is, you know, risk exposure. Regular audits are important, so reporting. Intelligence of threats, so we provide you live threat maps, but you can have other aspects. Osman covered some of the data that he got from CrowdStrike, so those are important data that you should actually look at. Implement regulation and compliance roadmaps, so even if you don't have everything implemented, at least, you know, planning that is important in terms of reporting, and then, of course, your breach readiness and the disaster recovery plans. Those are important.

The hygiene of data, meaning data backups, even if you have a malware or ransomware, right? So, data backups are important. Phishing attacks are the core to your applications, so awareness training, securing your IT infrastructure, a priori, or, you know, before something happens, and then, implementing some dual vendor approach because not everybody can implement everything, right?

So, there are holes, so look at a dual vendor approach, and then, of course, plan for incidents, so this is something that is very important, especially for your C-level executives that are now responsible. Osman? Thank you so much, Prakash.

All right, I would like to actually start thanking you first for mentioning and reminding us one more thing. Today, I was actually looking at something related to OWASP top 10 LLM vulnerabilities and risks, and I was thinking, okay, I should maybe add this to my slides, even though it was the shortest, but I forget it, but, yeah, it turned out that you are going to talk about it.

Yeah, I think it was really important that you also covered that. Thank you so much. We have a couple of questions. Maybe we can start with them.

Actually, starting with the first one, I kind of answered that. You also kind of answered that with our last slides, what are our recommendations, but you may want to maybe tell something extra. One of our audience asked, what measures should we implement to ensure compliance with relevant regulations?

It's very, very generic, very general questions, but if you want to suggest them like top five thing to keep in mind. So, first and foremost is just being aware of some of these compliance requirements and when are they in play.

So, many of these have already gone in play. The second, look at your own applications that you have in place and see what's required.

So, like you said, assessment of some of these security implementations, especially with your guidelines. Basically, your DevOps team, are they aware of OWASP for LLM, right? Are they using AI tools themselves? Are you scanning it for any kind of AI poisoning? Because AI systems learn.

So, if a hacker actually can just like we had SQL injection and LDAP injection earlier, right? Now, it's prompt injection.

So, I can feed a chat bot information that's malicious, okay? And it will learn from it and then play it back to me.

So, how you're protecting those, right? So, those are aspects that your development team needs to be aware of.

So, awareness of that. So, data hygiene, that's another critical thing that you should look at. And then making sure that when systems are being accessed, you know it, right?

So, maintaining some kind of storyline, whether it's a cloud service, who's accessing your storage systems, and how are they traversing to it? Do they have access to permissions? Those are important things to look at.

And then, of course, the client side protections are very important, some way of sandboxing beyond just the endpoint security that are implemented. So, zero trust architecture, you should look at security service edge architecture that you should look at.

So, basically, maintain an architectural best practice as well. So, those are ways of securing your systems, but also being aware of compliance mindset, right?

So, reporting on it. Perfect, yeah. I hope that this answers our audience's question marks. We have another question. You can start with this, and I can also contribute to this question. How do we manage third-party risks to comply with our regulatory requirements?

So, I think this is specific to supply chain type of attacks. So, if you have third-party systems that you're composing, I mean, I'll just take an example.

So, in the U.S., for example, if you have a banking system or mortgage system, and you're creating some kind of credit report on it, so you make calls to third-party here. It's FICO or Experian, and so those are API calls. It may not be just that. It could be you're calling an external system. Let's say those systems actually do get hacked without you knowing it, right?

So, your applications are now liable for any kind of hacking that went into place. So, client-side or business logic attacks, those are called business logic attacks. That's an area that you should definitely look at.

Yeah, exactly, and I would like to add also to this question. Recently, I've been working on attack surface management solutions, and there's this subcategory called third-party risk management tools, and I see that there are some dedicated tools that are focusing on the supply chain security and then go do kind of asset management for their suppliers in the second, third, fourth, fifth, up until ninth degree, like your vendors, vendors, vendors. I don't know how to put that in words, but yeah, and this is the risk coming from, where the risk is coming from nowadays.

It's not just your day-to-day business partner, and now we have some tools trying to dedicate themselves for this external risks arising from the third-party vendors, a supply chain. Yeah, this is something that you can also keep in mind. Another way of looking at it, Osman, is even though we don't provide it, but some of the aspects is risk exposure. So for example, if you have multiple systems that are being composed, being able to look at it from a single point.

So in the cloud, for example, even though you're not sending all data into the cloud, being able to at least get events correlated from multiple different systems, and being able to gauge risk of an user. So for example, is this user risky for my systems, right?

So that's, you can narrow it down to certain actors that are threat to your systems, right? So that's an active, proactive approach to securing your systems, right? So that's another way of, and some of these tools actually do provide that, but the risk mindset is very, very key here. Exactly.

Okay, moving on to the next question. Where is your solution at in regards to automated compliance gap analysis?

If it, of course, if it's relevant to you. So for us, I mean, we give you reporting in terms of scripts.

Let's say, for example, I showed some screens in terms of PCI DSS4, right? So you can take some, you know, a look at what are the various scripts that are going into composing an application, and then risks associated with that, threat levels with it. So that's something that you can look at from a gap analysis is, and of course, in terms of PCI DSS4, if you make any changes to those scripts, they need to be highlighted and reported. But the thing is, if you look at in terms of those applications, we'll give you in terms of PCI DSS4, but you can also use some scanning engines, scanning tools.

There are many different tools that are available to scan your applications from threats from just like you do for OWASP top 10, right? So what are the threats? They can scan, do penetration testing, or ethical hacking. You can do OWASP for APIs. You can do OWASP for LLM. And I'm pretty sure there are other scanning tools that have already implemented some of these aspects in terms of securing systems. So look at, you know, that for gap analysis on your application. All right. We have one more question. How does an organization stay updated with the evolving cybersecurity regulatory landscape?

I mean, at Radware, we have a very prescriptive way of, you know, because we are a managed service provider, right? So for us, we have to comply with some of these requirements. So first is being aware of what's coming.

Okay, so this, I mean, your talk was really excellent in order for, you know, providing information on, you know, what are the different compliance requirements that have come in place? So, you know, a couple of years back, we had GDPR. Now we have UAI Act that is in play. It's already gone into effect.

And then, but the implementation timeline is, I believe, mid 2025. There are other, there are other, especially in the US, there are some governance aspects that are going in, especially with EU, with AI. So there's the White House is actually working on some of those.

You know, look at, you know, there's many different forums that you should visit in terms of CSA is another example. The many, many organizations that actually provide very, very good information in terms of what's coming. Perfect. I think we have all the questions now covered. I can briefly share the poll results, actually, now that we have time, and then you can maybe share your final virtual test.

So, actually, all of our participants knew about, have a compliance management solution implemented in their organization. And one third of our participants did not know or hear about the UAI Act being enacted recently. And an important question, half of our participants are from North America and the other half is from European Union.

So, we have only people from United States. Oh, another person from European Union, just entered.

So, 60% from European Union and 40% from North America. These are. And that makes sense because most of these compliance initiatives do originate you know, some of the recent ones originated in Europe, but now they're actively being worked on in the US as well. Most of the large companies here provide some of these applications, right? Just SaaS applications and all of these, right?

So, it makes sense. And also, most of the managed service providers are.

Yeah, and then these new regulations are keep referring to each other. Referring to each other. When I go and see the changes log, for example, when I looked at this PCI DSS, for example, as you mentioned, and it is a huge list of Excel document. They refer to already existing other regulations that are established in the other regions of the world.

So, you can see them and they have in an unactive, you can see which regulation is it actually originally. And I've seen it when I was also going through FedRAMP. Yeah. And another good place to actually look at some of this information in order to, you know, other than the PCI DSS 4, OWASP is a very good place to look at NIST, N-I-S-T, which is the National Institute of Standards Technology. They have very, very good guidelines on security, right?

So, that's a very good tool to be aware of some of the implementation recommendations to keep your system secure. A lot of things coming up in very short order.

Yeah, I think that we will also see some updates. And today I just had to, you know, highlight five to six of them. I could not really go and cover all of them.

Of course, we know about NIST as well. It's like a backbone of the regulations in the United States mostly.

But, yeah, maybe next year we are going to be talking about the other newly enacted regulations and maybe some major changes to the big regulations that we discussed today. We never know. Last year we were already discussing that we need regulation to regulate AI and now we have already something in place to begin with, in EU at least.

Then, thank you so much for joining us today. And thank you so much, Prakash.

Again, it was really nice to discuss what is changing and what is relevant to the people doing business in North America and in the European Union and also the organizations that are doing business with these regions. We tried to cover the regulations affecting these regions mostly. But I'm sure that we will be also touching on some grounds of some other regional regulations because AI is becoming a global thing and these risks are touching every part of our daily life.

And I'm sure that we will be having more and more regulations implemented our organizational lifetime and in our daily way of doing security business. And, yeah, I hope to see you maybe in a couple of months, maybe next year, to see what's changing in this landscape. Thank you so much. I appreciate it.

Thank you, Prakash. Bye.