Explore how Check Point’s web application firewall secures Government applications with AI-powered detection.
[Anthony Jimenez]
Welcome back to CarahCast, the podcast from Carahsoft, the trusted government IT solutions provider. Subscribe to get the latest technology updates in the public sector. I'm Anthony Jimenez, your host from the Carahsoft production team.
On behalf of Check Point, we would like to welcome you to today's podcast, focused on securing government applications in this AI era using Check Point AI-powered WAF. Hezi Bahry, head of cloud security product management at Check Point, Alfred Trevino, cloud security architect at Check Point, Joe Ford, federal security engineering manager at Check Point, and Carlos Chiriboga, senior contracts manager at Carahsoft, will discuss the evolving WAF market, real-world government application attacks, and how an AI-driven approach to application security helps organizations identify malicious activity and safeguard critical APIs.
[Paul Barbosa]
So thanks so much. It's a pleasure to be here with you all. And always great to be here with our great partner, Carahsoft.
So we're excited about the content today. We definitely looked at the emerging trends in the market and wanted to bring to you some exposure to how we're looking at solving some of these challenges, particularly in the age of AI-powered attacks, industrialization, democratization of those attacks, and the speed by which defenders are having to react in this new world. So let's kick it off.
When we think about application security, is it apropos to say that security has always been critical for governments? Of course, absolutely. It's always been an imperative.
But one of the things that we're seeing is a steady rise on public sector organizations, particularly from the perspective of nation-state actors. And when we look at some of the attribution through our threat research, we see heightened increases in surveillance attempts out of China. Obviously, the geopolitical situation in the Middle East has given rise to a number of sophisticated attacks coming from Iran and Russia always being active in the surveillance attempts and intrusion attempts.
But these are some of the critical stats that we see. Weekly attacks up to 2,800, over 2,800, year-on-year, 717. And I think the most critical thing here is the days to exploit, the frontier models, as I stated earlier, are really, you know, really democratizing what used to be the domain of very advanced nation-state threat groups to be available literally to anyone.
And the concept of security through obscurity, maybe they won't find this vulnerability, are over. Everything today has to be considered in terms of risk. And we know that this audience wakes up and thinks in terms of risk and risk, risk mitigation and residual risk all day, every day.
So we're looking at this and saying, like, how prepared are we as an industry to address this time compression from the days to exploit generally having to be over 700 days? And I think it's important to think about the context. Why did it take that long in days past?
And we take this from the perspective of offensive security and our own threat research. In the days of finding a vulnerability, a true vulnerability, you had to be very careful about exploiting that vulnerability. You had to choose your targets wisely.
You had to make sure that exposing your tactic, technique or procedure to exploit that vulnerability was, quote unquote, worth it. And you didn't really want to expend or spend those rounds unless you knew you were going to get a return. Well, in the age of frontier models, that prediction or consideration is compressed.
These are available. They're happening at hyper speed, and we know that there'll be more of them. So let's take a couple of examples here.
So the first was an attack on the US Treasury in 2024 by Silk Typhoon, a nation state actor. And the compromise was essentially an API key compromise. So a nation state actor stole an API key and they used that key to bypass the authorization.
They were able to access the sanctions office and exfiltrate over 3,000 files. So again, one API key stolen. There was no malware and they were able to exfiltrate data.
Why is this important? Because you would think, well, we would have a signature that would detect this sort of behavior. But a signature essentially wouldn't catch what seemingly was authorized use of a stolen API key and trusted the API key.
The authorization looked at it and said, all good to go and off it went. In the second example, this was a breach on using SAP and it was a true zero day. So in this example, the attacker used an AI engine to scan for exposed endpoints with this vulnerability.
They leveraged HTTP to the web to the web endpoint. Then their shell was deployed and they had full control. So there were no credentials here that were abused.
There was no malicious file upload, but there was a path to remote execution. Again, a signature would not have caught this. Right.
You think about what happens with signature. You have to know something. And even in the form of knowing that there's a zero day convicted out in the wild, you still have to develop a signature.
You still have to deploy that signature. And when we think about this and this is a preview into what we're going to get into, we really wanted to reimagine what possibilities could be if you didn't have to rely on signatures and you were able to understand the behavioral pattern of every application that you are protecting behind your app stack. And that's the approach that we took.
And we want to tell you a little bit more about that approach as we get into the content at this time. I want to welcome Alfred to take on the next sort of the deep dive into, OK, that's what we're doing now. Let's talk a little bit, Alfred, on how we're doing it.
[Alfred Trevino]
All right. So one of the ways today that we look at as far as like where I where AI is actually being fueled towards is I don't need to convince many folks in the audience that AI is definitely a massive impact on the cybersecurity side. However, attackers now have access to powerful AI tools such as we know, right, whether it's cloud, whether it's chat, whether it's open, all of them are kind of moot points.
The most important piece is that I want you to, you know, to retain from this is making those attacks faster. They're more precise. They scale very well and they're able to easily be executed.
Right. So when we look at it, when we look at how it's changing the security or application security landscape, it basically comes down to these four bullet points. Right.
What are we going to use to protect us from the fast powered AI that's coming out? And of course, how are we going to address the vulnerabilities, those next day exploits? And then, of course, the AI driven attacks.
Right. Those that we mentioned a minute ago, they can be autonomous. They could be fast moving and they can be very, very precise.
And so let me showcase just a little bit of how we take care of that, or at least what is compromised are composed of when we talk about our API and application security with our web. So this is exactly what we think when we built our own platform. Right.
Those areas that we saw Paul mentioned earlier, which, of course, is some of our leading principles, right. AI based behavioral application where detection, web attacks, DDoS, layer seven, those are becoming more key and more fundamental as things are evolving quickly and moving out to the edge. We're also prevention first.
Right. We we do a fast path to prevent in just about everything and anything that we do from from any of our products and solutions. We block unauthorized scripts, we're running in user browsers and then, of course, being able to scale this and be enterprise grade, enterprise DDoS, enterprise CDN, those capabilities we started to enroll into our WAF solution to give us what we what we need for this day and era to be able to protect and being able to help keep our customers mitigated.
As mentioned, our WAF is based on AI and the way that it works. I'll show you that in a second. But we're able to develop a unique technology to detect malicious traffic, right, based on some small indicators of attacks inside the request body.
We're not looking for a long regex string or complex CPU intensive process. What we do is find smaller pieces that indicate a possible attack, correlate that information back, and that gives us an unmatched detection rate and the lowest false positive rates in the industry. We actually have an article that's published out there in the public WAF comparison project.
You can feel free to Google it. But it is we try to take an unbiased approach to see what the other solutions in the industry are doing, how they sit up to par. And we provide that to the public as a as a as a, you know, as a free solution, open source solution to go ahead and just also say to kick the tires around.
We've drilled down a little bit on what, why or how we do what we do. But let's just talk more importantly on some of how those web attack rules and signatures work, right? There are two two opposite situations that originated in the fact that the detection is based on finding regular expressions in a sequential sequential way hiding inside a web request.
So when that first rule, right, it could be too tight, it could be too specific. What that comes down to, it's just bad for security, right, because it has a very low rate of false positives. And second, when the rules are too loose, they're good for security, but has a high rate of false positives.
And that requires an intensive exception for management. And one more important aspect or important aspect of this solution is the way the signatures are created. And Paul mentioned this earlier, when we talk about zero days, when we talk about unknown threats, we so we'll just we'll call it virtual patching in the wild.
But that's how we were ultimately able to discover those that didn't have signatures for. We we have the Intel, we've got threat cloud, we've got AI, we've got machine learning, we've got a whole host of a large Intel data set with hashes, and combined with our engines and indicators to kind of correlate that information together. That's how we're able to actually do the virtual patching, securing what is out there that hasn't been signatured yet.
And that's what we we've been successful with. And this right here is just a very quick idea of what it looks like to eliminate those manual rules and signatures. We just we don't have just that single engine.
And I discussed it just a minute ago. We've actually got two of them. And of course, that first engine is actually going to find suspicious indicators.
It's going to attack the level of the risk they present. Right. And in this in the screenshot here, right, that bold red indicator, those are the most risky and the pinkish are the less risky.
Either way, the engine weighs these indicators, reaches a scoring for each request. But in order to reduce the false positive rates to minimum, we have a second engine. And that's the AI engine.
It's a contextual engine that takes the request in terms of the user, the crowd that it's with, the trusted users in the application surrounding it. And it answers these key questions. Have I seen this user in the past?
Have I seen these indicators with more users? Have I seen these indicators with my trusted users or when using an app? Checkpoint came up with the new security practice to use these AIs to build application where attack indicators analysis and we narrow down these signatures to smaller particles that we call attack indicators.
And when finding these indicators and correlating that information back with other attack indicators using this AI model, that points on the riskiest of requests. And of course, this process keeps continuing and it keeps learning. And that is our first engine for detection.
That second engine, the AI engine based on the user's context, behavioral, the crowd context, trusted users, context, behavior and application awareness. Those there are going to be where we start to look at the user context, the historical user behavior. Right.
We've seen this maybe a thousand times before. And now all the previous requests were benign. We look at the crowd context and we look at many more of the indicators in the request, not just those single and the ones that I talked about a minute ago.
It's if it cannot be that all the traffic is malicious. Right. Then we move on to the trusted users context.
And then by adding the trusted users, we can compare right those indicators from a trusted source. And then, of course, we move on to the application and the content context. Those right there are going to be where we start to do the application content learning.
And again, those indicators are perhaps per headers, body payload. Those are the main wrapper for providing the contextual intel of how we're able to do what we do today.
[Hezi Bahry]
Everything Alfred just told you was brought to the test with a few in a few cases, those few cases where where we were able to show that our technology was not only a theory, but also was able to block in practice one of the many of the major zero days attacks that we were able to see in the in the last years. It started actually the first time that we vividly saw it was with the log for Jay, which was it was a quiet Saturday, a Saturday morning here in HQ. And suddenly we got a notification on this major CVE that is running around.
And we took the exploit that was published immediately. We ran it through our web application firewall and was able to see that we got a block, a block log. And we were very happy to see it.
Then we had to move it. And lately we show it how we were able to block the reactor shell. And what's interesting about it is not only the fact, by the way, Alfred, you're showing with the notes and the next slides, but it's OK as well.
But lately, we actually ran through a study that was very interesting where we took CVEs that were published and looked for them in the in the historical logs that we saw in historical traffic that we saw. And amazingly enough, that we saw the exploits being used in the past. And as as probably Alfred mentioned before, we see that the the the window of a from CVE being published to the fact to the minute that is being being used is getting narrower.
And right now, what we see, it's a mirror reflection of everything that we see the CVEs being used in the wild before they are being published, which is a very worrying phenomenon. And this is this is the reason that what we are now looking into is something that we call minus zero day attacks, meaning that these are indicators that are being used in the wild before they are being published, which is a quite worrying. As as mentioned before, we were able to show one on an open source testing.
We called it the WAF comparison project. This is something that you can Google yourself and we're able to show that on the ratio on legitimate traffic and malicious traffic. We again, it's a it's a you can go in and use it to do it yourself.
It's a it's a kind of a serve serve yourself a test. You can see that our WAF was able to get to the highest threat detection rate and the lowest false positive rate, which which is quite amazing because it means that it gives you the highest security with the lowest operational effort that you need to apply into your into your WAF. With respect to our API discovery and security, we give our on top of our WAF, we give our users another layer of visibility and security with a deep granular visibility to our organization, to the organizational APIs with frequently used API shadow APIs and deprecated endpoints with a continuous learning of APIs in real real time production on real traffic and doing it automatically.
That's it. We give on top of this, we have a strict schema enforcement, what we call the positive security with AI driven malicious payload detection, of course, as a negative security. We are looking for those indicators, the indicators of attacks that we just discussed inside the payloads.
And we are protecting known APIs and unknown attacks. We are comparing our traffic against learning schemas and highlighting APIs, the addition or removals or any changes in the APIs are being adopted in the schema generation that we have. With respect to our DDoS, so we in our platform, our platform is containing is coupled with a layer seven DDoS with a domain based learning.
We have a domain based learning of a normal behavior of your applications. Again, AI based, everything that we do is AI based because we believe that to fight AI, you have to adopt AI. When a site is experiencing a sudden traffic spike, our layer seven DDoS recognize the legitimate traffic while blocking abnormal traffic patterns.
With respect to layer four DDoS, we have a layer four DDoS that is capable to absorb large volumes of traffic without impacting your application availability in the sense of in the sizes of multi terabytes DDoS that we can absorb without overwhelming your infrastructures and connectivity. Overall, we have a resilient global network of automatically distributed traffic across the network. As you know, lately, with respect to bot management, so our bot management module is here to protect your business application, to make sure that no automatic attacks or automatic flows will impact your applications.
We're using, of course, a hyperscalers intelligence sources for malicious IPs where we're about to adopt more intelligence capabilities to even tighten this capability. We have advanced bot mitigation and control for good bots, for bad bots, for AI bots. It's a new category that was added lately.
We're using, as I said, a hyperscale intelligence. We have a deep fingerprinting of bots and the ability to detect good flows and bad flows. We have an escalating process of challenges, starting from the simple JavaScript and going through an unseen challenge or proof of work, and then going into a more severe challenges that we are putting in front of flows that we believe that are automatic or bot related.
And as mentioned before, bots are getting more and more sophisticated and we are putting a lot of emphasis in making our bots much more advanced. So with respect, this is something that is not part yet of the full FedRAMP authorization that we took, but in the future, we definitely want it to be part. So I'll give you a quick peek into what we do in the AI security part.
Again, this is a tightly integrated to our WAF and API security SaaS. Checkpoint lately, about a year or a year and a half ago, acquired a company in the AI security space. Its name was Lakira.
Lakira has a few notable advantages on top of other AI security companies in the industry. The first one being a multi-language company. Our LLM is capable to adopt more than 100 different languages and able to detect security events in those languages.
It provides high performance. This is something that is really important due to the fact that we want to keep the conversation of a user that is here to get some kind of a client support or a client usage experience. We don't want to hold him and let him wait for a long time.
So anything above 200 milliseconds will provide a bad user experience. And we see that Lakira has an amazing performance in this respect. And it's natively integrated in our application security platform, which gives you all the visibility, all the capabilities that you already have as part of our platform in a native experience all together.
So here we see just the relevant use cases for AI security chatbots. So of course, we have the prompt injection. Again, this is yet again an input to our applications.
So attackers can exploit it, can exploit and try to run a prompt injection. We want to make sure that the LLM is not being manipulated. Please give me the content.
And LLM has a tendency to be obedience and to get tired if they're being asked repeatedly and long questions and in different variants trying to attack, to jailbreak the LLM, to provide you some kind of a data on anything, on the service used, on the servers, on the users, on everything. So this is really important. We want to avoid a data leak, not to provide you files or anything else.
And we want to make sure that we're not being abused. You know, someone can go to your LLM and start asking, how can I do a cheesecake? We don't want it to be.
We don't want to exploit to exhaust your resources. It's the same as other attacks that are targeting your infrastructures. So all of these are being secured by us.
[Joe Ford]
On that topic, as you talk about that, talk about why it's so much harder to protect these chatbots than it was to protect traditional web applications, right? With traditional web applications, we knew what our fields looked like. It was very fixed fields.
There was no variable in what that field would look like. That changes with their chatbots. And so protecting that becomes much, much harder.
Can you talk about that a little bit?
[Hezi Bahry]
Yes. So first of all, the LLM is significantly less, the model is not decisive, meaning that you can ask it different questions and it could get, it could reply in different ways for different, if you ask a couple of questions in the same sense, but in different way, you can get different answers. And the models are, you know, sometimes have access to applications, most precious data, databases, credit cards.
And the access that those models have are quite vast in our world and it's going to get, you know, greater as we go. Again, the application, when you have just a web application, everything is known. If someone wants to come and put his username and password and he's doing it in the wrong way and he's trying to extort it or to manipulate it, you understand what are the templates to expect and how to block it.
Here, the level of freedom of use of texts are much greater and it gives much more space to attack in different ways and to manipulate the models.
[Paul Barbosa]
Hezi, I think, you know, one of the things, the way I've been thinking about it, too, in this context is like, you know, the traditional controls that we have understood language of machines, right? Code and HTTP requests, and these models, the executable is natural language, right? And so there's no tool that exists that can understand natural language and the multitude of variations.
And I think we're saying it the same way, but the way I think about it is, you know, it used to be the domain of exploits had to have very deep technical understanding of how code works. And now the only limit we have is the bounds of human creativity, which we know has no bounds, right? So, like, this movement is so fundamentally different than the controls that we put in place, which is why I think, you know, as you and I have talked about, how do we even think about this differently?
This existing controls just simply don't understand, right? A new class of controls need to be invoked.
[Joe Ford]
Well, you're dead on the mark, right? And that's why it's so important for us to look at this from a new lens, right? We need to look at this from the lens of being able to control natural language and being able to frame this around natural language context, because for the last 50 years, when we look at applications, it was very much constrained to a very, very specific code base.
And we're now past that. That is no longer a constraint for us, and it's no longer a constraint to the bad guys either.
[Hezi Bahry]
I agree. So we came from a very strict world to an unstrict world. And the good thing, the good news is that there are some signals that are combined, that are shared, like the user agent or the user identity, the ability to fingerprint users and understand who they are, to understand that this is not a bot that is trying to manipulate us.
So some of the signals, not all, and I'm not saying that everything is shared, but some of the signals could be combined and help us to get to a much more precise and accurate level of security prevention. But this is a very interesting topic, and I'm sure that we could spend more time discussing it. And I don't want to take all the time that Alfred will have for our demo.
Just to summarize the discussion on our SaaS, to share that we have our SaaS platform is based on AWS Gov, and it takes really five minutes to onboard on it. Really simple. Just change your DNS record and everything.
All the traffic will be directed to our servers. We will run the security and forward them in a filter traffic. The filter traffic will be forwarded to your upstream in a secure manner.
We also provide a configurable load balancing if you need as part of the SaaS. The licensing is very simple. It's based on the number of requests that you use, no number of applications, no bandwidth, no all kind of dimensions.
Very, very simple. And we provide a tight SLA of five nines. So just to summarize this part before jumping into the demo.
So application security ready for AI scanners. The autonomous scanners are super powerful tools, and we have to make sure we have to understand that the whole rule updating cycle does not work anymore. It is less efficient in this sense for the autonomous AI scanners.
We're looking at the minus zero day AI detection. As I said, we see CVEs, we backtrack to the history, and we found them where we can find them used in the wild. This is really worrying that today people or organizations are using CVEs instead of going and publishing them and showing that they have to be patched.
And of course, the operational simplicity of our platform provides you an unmatched operational advantage. You don't need to manage infrastructures. You don't need changing infrastructures in your environment.
Just change your DNS record, and you're there. What we're trying to do is to keep a couple of main principles for our product as for this product and for other Checkpoint products is to be AI-based, to think on prevention first, and to keep operational simplicity. These are the three principles that we're trying to follow in each and every product that we build.
And I think that the WAF specifically is one of the products that we exceeded our own objectives with making it super simple. And this is the reason that we see that many of our users are in prevent mode, getting the benefit of this solution with very little, a very small number of exceptions, which we are now trying to insert as part of the learning. So all in all, I think that these are the three principles, and we're following it across the board.
[Joe Ford]
Hezi and Alfred, thank you for that really great points. I do want to mention to our audience that this is something that will be available inside of Checkpoint's FedRAMP boundary. We have completed our full audit.
We will be launching this live within our FedRAMP boundary in about the next 20 days. So really want to give you a preview of this. This is something that is available to our government customers.
So I really urge you to reach out to us so we can have conversations around what's available within this platform. Stacey, do we want to have Carlos come in and talk a little bit? Yes.
Thank you.
[Carlos Chiriboga]
All right. Thank you, Stacey. Hello, everyone.
So I'm Carlos Chiriboga. Again, I am a Senior Contracts Administrator under our Contracts Department here at Carahsoft. I just want to kind of touch briefly about how you can access Checkpoint software through Carahsoft.
If you want to procure through a multitude of our contract vehicles that we have available. So Carahsoft is a contract holder. We have many different contracts that have Checkpoint software available.
For some context, our team is made up of experts that kind of work under, we're kind of split between federal, state and local and education contracts. So we have experts that kind of manage each of these different type of contracts under their territories. Some of the notable contracts that we have Checkpoint software available under are GSA, our GSA Schedule contract, our NASA Soup 5 contract, as well as our NASPA ValuePoint Cloud Solutions contracts.
Those are our largest, I want to say our largest federal and state and local slash cooperative contracts that we have. But if you want a full list of contracts that we have Checkpoint software on, you can use that by checking the link which goes to our website and it has the full list of contracts that are available there. To kind of get up, just to keep things very simple and brief, the best way to kind of work with us to access Checkpoint software is, you know, working with your sales POC at Carahsoft.
If you do not have a specific point of contact, you can go to the checkpoint at Carahsoft.com email alias to get in touch with our vendor team that manages the relationship with Checkpoint. And they'll kind of bring our contracts team in to discuss anything specific that, you know, or any or discuss any contracts questions that you might have or, you know, we may need some assistance to the process that might need to be escalated. How it typically works is that we are sales and contracts departments will need to be kind of on the same page and talking to each other.
But generally, reaching out to the sales staff here at Carahsoft is the best first point of contact. And if by any chance you do need to reach out to our contracts team directly, we do have contracts email alias listed as well, which is just simply contracts at Carahsoft.com. Again, we'll probably need to bring in our sales team just to make sure that they can talk about anything pricing related or get you guys a quote as soon as possible.
But, you know, we'll both be involved at that time. And, you know, we're happy to be available at any time of the day for any reason whatsoever. So that is pretty simply how you how it would be best to work with us to access Check Point through our various federal, state, and local and educational contracts.
[Anthony Jimenez]
Thanks for listening. And thank you to our guests, Hezi Bahry, Alfred Trevino, Joe Ford, and Carlos Chiriboga. Don't forget to like, comment, and subscribe to CarahCast, and be sure to listen to our other discussions.
If you'd like more information on how Check Point can assist your organization, please visit www.Carahsoft.com or email us at checkpoint at Carahsoft.com. Thanks again for listening and have a great day.