Driving Security through Observability: Transforming Application Risk into Resilience

Hello, good morning, good afternoon, good evening, wherever you are. My name is Jonathan Care and I am a lead analyst in KuppingerCole. And with me today is Amir Erel, Director of Marketing at Algosec. And today we're going to talk about driving security through observability. So before we start, just a couple of housekeeping items.

Firstly, you're muted centrally. We're controlling these. You don't need to mute or unmute yourself. We may run a few polls during the webinar and discuss the results during the Q&A section, which will be at the end of the webinar. If you have any questions for me or Amir, please do enter them using the Livestorm control panel, the questions tab on the bottom right.

Finally, we are recording this webinar and the recording and the slide decks will be made available for download in the next few days. So without further ado, please make yourself comfortable and I hope you enjoy this webinar. So what I'm going to talk about is following four items.

First, I'd like to take a quick look at the problem and an overview of the solution around security, observability and security policy management. I'd like to look at how security policy management is maturing and then talk about how AppSecOps, which is a new discipline, can scale to meet the needs of the enterprise. And finally, I'm going to round off with some read world results that we have in cup and Nicole, and I'm going to hand over to Amir, who's going to talk to you in detail about the Algosec solution. So without further ado, I'd like to open with this thought.

In the time it takes the security team to approve a policy change, competitors have already deployed three new features. And this underscores the problem with traditional methods. We now have dynamic applications distributed across clouds, containers and, of course, on premises systems. Our traditional policy management features for anyone who's done this or even seen it done, it's manual and, of course, bound to infrastructure. This creates delays, misconfigurations and security risks, which we all know are the three causes of data breaches. And so we need a better way.

And that better way is application centric security policy management. What is this, I hear you say? We need to manage connectivity from the perspective of the application, not the network. And we need to define policies in business terms. So allow the CRM to connect to the customer database. We need these business logic rules to be automatically translated into technical policies, the firewalls, cloud containers, endpoint controls and so on.

Even, of course, deployment is code, infrastructure is code. And we need to align our security teams, our application teams and our infrastructure teams on a common language. And something I've seen as a practitioner is that the security teams and the dev teams often speak very different languages.

Again, leading to breaches, misconfigurations and delays. So this is urgent. You need to do this now. Because cloud first microservices are increasing the policy scale 10 to 20 times. We have a geometric increase in our policy complexities, where we had a monolithic application before, with one interface to the end user, with another interface to the data repository, with another interface perhaps to some middle logic or to the admin interface.

Now, of course, we have many, many microservices, all interacting, all sharing data, all brokering connections, all requiring authentication, authorization. And this velocity breaks traditional approval cycles. We can set up and destroy these things in instance. And we do.

And, of course, when it comes to compliance, when it comes to audit, if you say you have this highly dynamic structure, well, what's connecting? We're not quite sure.

Well, what's it connecting to? Well, we don't know that either. It's problematic. So. Let's look at how solutions are maturing. I think there are four stages of security policy management maturity. The first stage is the discovery, the mapping, understanding what's out there. Secondly. We need to be able to create and automate policy components. For enterprise.

Finally, we need a way of orchestrating and implementing these policy components to seamlessly interconnect with each other. And finally.

We need, of course, to monitor and optimize the results so that we can see these things are meeting our business needs and indeed how they can be improved in June. So let's look at discovery and mapping. What do I mean? I need to identify all services, all APIs and all flows. And as we know, there are two types of APIs. They're the ones that you know about, the ones that the teams say, hey, we built this API and the ones that people don't know about. And these can be ones that have been decommissioned. But are still active, they're still connected to a data repository.

These can be ones that scratch a developer's personal need and perhaps they are poorly secured. And, of course, we need to identify flows. Where is our data going? I've done in my past, I've done auditing. And one of the key things I needed to understand was where the data is going. What applications were handling it, transforming it, transmitting it and storing it. And secondly, then, given that we have this hybrid environment, I can be an AWS, I can be an Azure. I could be in Google Compute. I could be in my data center somewhere in the west of England, if I wanted.

How do I map the dependencies across these hybrid environments? Bearing in mind that these environments themselves may be a layer of abstraction. And they can lift, move and shift in order to meet various different infrastructure needs as well. And finally, having established and understood this highly dynamic, highly ephemeral, highly evolving environment. How do I then keep that map up to date?

Well, automatically is doing a lot of heavy lifting in that sentence. So let's move on a little further and let's talk a little bit about scaling. How do we scale AppSecOps to meet these needs?

Now, as I said, AppSecOps is a new discipline. The idea that we can automate, control application security in the same way as we've automated and control traditional infrastructure protection is new and interesting. So let's take a look. The first thing we need to do is use business friendly templates. The reason for that is that if we are, again, creating a layer of complexity, if we're not allowing the business analysts, the data users, if you like, the data controllers, GDPR speak from over here in Europe, then we have a challenge because there will be resistance to using.

So we need to make this system easy to use so it can communicate in a human language rather than some artificial pseudocode. Secondly, we need to integrate with the CICD. So we need to make sure this thing goes quite technical, quite deep into the dev process so that as we change the business requirements using our business friendly templates. As I was saying, we need to integrate with the CICD. So we need to translate these business requirements using the business friendly templates into code or pseudocode that can become part of the dev environment.

And then, of course, we need to simulate changes and validate them before they go live. The second stage I mentioned is to orchestrate and implement these changes.

As I said, we're working in a highly dynamic, highly ephemeral environment. So we need to be able to auto generate conflicts on the fly for our firewalls, for our cloud, for our Kubernetes containers, whatever we have. And we need to be able to push those out with a high degree of confidence that they will work without manual review, without manual testing.

And again, for many of us, that's something of consternation. And indeed, it may be that actually that's a compliance issue for some organizations. So then the question comes, how do you validate and ensure your auto generated conflicts will pass audit?

Well, of course, one day, one way, of course, is to make sure that your policy components have been audited. So you know that whatever they're put together is likely to pass audit. And of course, leading on to the second point, we need to be able to sequence changes safely. And what does safely mean in this case?

Well, first of all, a high degree of confidence that the changes we make will work. And I talked about making sure we use trusted components. The second thing, of course, that anybody who's done any IT change will know is having a way of rolling back. So that third point is, yes, supporting rollback and versioning. Making sure that the changes can be rolled back to a previous version should the change not have the desired effect. The final stage, which I think is important. And once we have this in place, we need to make sure that we can manage and control the effects.

We need to make sure that we can detect drift. As we know, many IT systems experience drift, especially any system with any kind of data-driven machine learning type components. And indeed, obviously, we get venture into the world of LLMs. Drift is a major consideration. As business requirements change, rules may no longer be necessary. So we need to detect when rules can be retired. And we can have a process for safely and automatically doing that.

And, of course, we need to find risky gaps. So, for example, if we do find a partially accepted or a partially documented API, which nevertheless is now being reliant on a business process, there's a risky gap there. We have to manage it. There's a business process relying on it. But how do we then make it safe? How do we understand whether our policies align with our requirements for performance and risk tolerance? There's a whole piece around risk tolerance, which, again, is only emerging as a discipline in AppSecOps.

And clearly, during the audit process, we need to have confidence in what we are reporting to the auditors so that we can establish an accurate picture of what is happening. So, finally, just before I hand over to Amir, I'd like to talk about some real-world results where we've seen this working.

So, what we have seen across the customers who have adopted this and will talk to us in our surveys and our research cycles, a 70 percent improvement in a policy cycle. So, we're talking about going from, yeah, days to hours or even hours to minutes. We're talking about an improvement of 80 percent or more in compliance efficiency, getting to compliance, and then maintaining that level of compliance. And there's an improvement of 80 percent.

And in one particular case, which I found very interesting, over 15,000 obsolete rules were removed, rules that were seen to be no longer needed, exposing data stores that no longer need to be exposed. Which, of course, again, leads to a step change in organizational security.

So, thank you for listening. I hope you've enjoyed this. I'll be back for the Q&A.

Until now, I'd like to hand over to my friend and colleague, Amir, who will talk a little bit more about AlgoSec in detail. Thanks.

So, while we saw together with Jonathan where the market is heading and some of the challenges it may impose on you guys, I want to do with you together now three things. Embrace the reality, solve some challenges, and see the opportunity. I'll try to show you some practical ways and tools for going through this path.

OK, sounds like a plan. Let's go for it.

OK, so there are tectonical changes happening in your environment, in our environment. The good news, guys, they are not unique to your environment. It's something that everybody is facing. You are not alone in that. That's the reality for all of us. Those can be big cloud migration processes, adoption of micro-segmentation tools, adopting a ton of tools to monitor those activities, to highlight more and more problems to be solved.

And, of course, none of that with additional headcounts, right? So, as I said, I have some good news. You are not alone. That means that some of us thought of ways to deal with those challenges. And while all the technologies are changing and tons of tools in the market to solve them, there is one solid ground that is not changing. That's the existing of the application that drives all those changes. Migration between the technologies that the applications are using has some obvious pains, right? Generate a lot of new work with no additional resources.

It brings in risks and complexity, risk of security, risk of outages. However, as you know, we change. There is also an opportunity always. And the opportunity here is to increase the security bar, clean the house, or at least the warehouse, and streamline some processes. But I know, first things first, let's take care of the pains, the timely processes, and the risks they impose. What do we do in order to reduce the time and the risk? We need to know what we are dealing with and prioritize the job. That's what I learned as a product manager. That's like my key role, to prioritize things.

And prioritization, when it comes to security state, is a combination of the level of the risk, the area in the network, or the area in the estate. And the complexity of the work needs to be done.

Yes, and we usually go to low-hanging fruit. But in order to do all those things, in order to do a fair prioritization of the work, you need to know what you are dealing with. And that's where I connect to what Jonathan just told us. We need to see the applications that are structured on top of the technology that we, as security experts, are trying to fix day in, day out. How do we know what application we have in our environment? So we are at AlgoSec struggling with that for a decade and more, and we have many ways to discover applications. I'll present you some of them.

The latest is using AI. That will help us build the application documentation, in case you don't have a clue what you have in your environment. And it does the following.

You know, AI is excelling with language and with words. And guess what? You have those descriptions, comments, tags, many words describing many infrastructure parts in many places of your security state. Usually on cloud assets and on security, entry security rules in the policy that's in the ticketing system. When somebody asks for something, he may name his ask, he describes. So all of those tools we inject to AI and we discover application.

The good news here is not just that we are capable with that to discover the application, discover the connectivity needs and the name needs, which is really very challenging. Since we are doing it on ticketing system, we know also to recognize the contacts, the owners of those applications. Who asks what in that specific application or intent that groomed a few requests. Isn't that great?

Well, I'm sure that AI is a tool to discover whatever you haven't documented for years, grabbed your attention. And AI is indeed a great way, but there are many other ways to involve application. And you know what's the best way to do so? Just to have a solid process in the first place to build the application on the fly. Whenever somebody is asking something from the security teams, from the security operation, from the network person, through ticketing system, service now, any other tool. Just add one small field, ask him to select for one of the existing application or name the new one.

We at AlgoSec recommend to adopt an application centric approach from day one. If not done so far, it's always a good time to start with. Our tools at AlgoSec are built to do so. We have change management tool. They are built to introduce application. They are built to connect to different application source of tools in organizations, so you get the list. I'll demonstrate later some of those capabilities.

Here in the slide, you see other ways that we have to discover applications from AI and from the policy tags, names, comments and descriptions, from external ticketing system, from documentation existing, from service, from CMDB. From directly observing the syslog, netflows, cloud flow logs, firewalls logs, wherever you have information around traffic moving from one host to another, we can look at it, find it, annotate that, groom it and create an application out of it. I promised also an opportunity, right? So what's the opportunity with all this hard work?

First opportunity is to keep your documentation tight. Most of the organization I encounter struggle for years to document why they have any security guardrail in their estate and what's the policies that need those guardrails and what are the rules serving and so on. Keep your documentation tight through good processing place for audit, for compliance, for future changes. It's also an opportunity to tighten your policy, decommission redundant rules like Jonathan mentioned. Allow explicitly required traffic like Zero Trust philosophy asks you to do.

Maintain the intent for any records, any new rule entry. I promise you that those processes will fasten your processes, make them more secure. And the last, maybe most important opportunity here is to partner with the application subject matter experts that you have in your organization. Let's talk about this partnership. This partnership starts with understanding that their jargon is different than ours. Let them submit their needs, their requests for changes in their own jargon. Let them self-service themselves.

Whenever something that they think they need new is already working, already secured or may impose new dramatic risk, let them know about them. Let them know where their ask stands. Whenever possible, whenever they are not breaking any guardrails, any need for specific approval, adopt a zero-touch approach. Or in other words, make the request fly automatically from request to provisioning in the policy itself.

Of course, we have tools to do so. We have tools to recognize problematic cases when a specialist is required and easy cases when we can trust the automation to do everything for us. But let them do that. Let them self-service themselves whenever possible. If they are self-serving themselves and sometimes we are interrupting, be transparent around the process, the SLA, where do they stand with their ask. If you want them to use your tools, make sure they are integrated with the tools they already have in place, like ServiceNow or other IT solution.

And a good trick here is whenever you have an end-to-end process, tools that you've adopted, with all stakeholders using those tools, compliance is built in because everything is documented and you can always go back and look into the history. Let's look at one or two examples according to the time that we have. The first example is maybe the most trivial one. Typical process exists with many organizations in different levels of maturity for submitting a change request because something has changed in the application or because a new application is being introduced to the organization.

So it starts with submitting the request with tons of different channels from e-mails and Excel and Jira and ServiceNow and you name it. Then governance teams need to approve it line by line according to the guidelines, according to the policy, making sure it's not breaking anything, making sure it's not introducing new risks. In order to do so, somebody needs to manually understand the connectivity path, check where in the network this change exists. Then engineering team needs to design the required change. Engineering team needs to build a detailed plan.

Somebody needs then to provision that, to deploy that, to change the policy. And of course, not to forget at the end to let the know to the end user that his request was solved and he can start using whatever he wanted to use. The modern way to do so, with the tool that I'll show you later, is to move from this manual labor of people doing things in different channels to a solution that you just need to monitor what happens in it. So the user design the required change of the application, as I said before, in his own jargon. He's changing the name of the host to be connected to what and so on.

He's doing the tool that was designed for that. The tool, our tool, named AppViz, check for him if there is a need to change the network or it already works as is. If there is a need for a change, AlgoSec automatically generates a plan. A governance team can have an oversight on this plan, decide if he wants to change it or we just trust the recommendation. Then engineering can also validate the recommendation to look at the nitty-gritty details of what needs to be changed and how the rules are being created.

And again, greenlight that or change it if you would like. That's where I said we recommend to just let it fly automatically whenever there is no specific special risk. And AlgoSec will create the change, validate the change, provision it in the network, document that in our tools, let the user know that it's done and close the loop. It's all ready for later on the audience. So that's one example of a process that can be streamlined between the application owners and security owners. Another short example is the rule validation, also mentioned by Jonathan.

It's also now very strong with compliance. The market is going there with regulations like DOA and other in different places in the world and sometimes with internal governance. We are being requested to revisit the policy and check that it's still required. In order to do so, you need to understand why those rules, those descriptions, those details in the policy were put in the interface in the first place. So in other words, you have the challenge of correlating between the firewall entry or the other filtering technologies, details in configuration to the intent that generated.

In order to do so and to revisit the policy time after time, you need to collaborate with the person that generated this intent. This would be the application owner. The old way, wait for an audit, pull the policy tool in Excel or other tool, massage it, filter, search, group. The questions that we have to a set of rules, find the business owner or the person that can say to us, yes, I still need that, don't touch it. Even to him, a batch of rules, wait for it, yes, I still need it.

Or in the worst case, he's just suggesting that he doesn't need it and then sneaks to delete, create a deletion candidate, trigger a process of verifying that we are not causing any outage, try a lot and tighten the policy. The modern way, the application-centric way is to invest the time, first time to onboard this application, to document the rules. Our solution will help you tie policy rules to the application to do this mapping. As I suggest with AI, you also can say who is the owner for each application or for each set of rules. And we can set expiration date for your application.

The system will automatically notify the expiration, the user, the end user, which is the application owner or subject matter expert, can decide on the future of the connectivity flows within it, either delete it or edit them, do whatever it thinks needs to be done intent-based with this. And then the security team can review that, approve it and provision it.

Here, again, there is a cool trick because that's not just a process or a tool that helps you move things between one person to another. That's a tool to share the responsibility to this heavy lifting work of recertifying your policy. Security people are looking at security, application owners looks at the connectivity needs. If something goes down, it's because at least the application person and the security person did a mutual mistake. So sharing responsibilities is very important. It also reduces a lot of load. How does it reduce load?

Because one application, one expiration date is usually combined with many connectivity needs. And each connectivity needs combined with many, many policy entries, rules, contracts. And so one click of certifying one application can be equal for certifying of hundreds or even thousands of rules. And that's not the tool. That's the concept of certifying applications instead of certifying rules. How that looks like in our solution. So here is an example of our tool.

Up this, you have in the left-hand side the application names and you have on the right-hand side the grid showing connectivity status, active, draft, pending implementation, the application lifecycle, testing, production, so on. The source where this application was discovered from the network, from the logs, from different methods that we have. The number of flows and their connectivity status for each flow is the connectivity of an application. We'll see it in a second. And then the right-hand part of the slide, the certification status. Who is the owner? What's the expiration status?

What's the expiration date? When it was last certified and so on. And you can add columns and remove columns. You can filter all that. And you can very easily discover what are the most problematic applications or what are the most problematic applications that don't respond very nicely with you. Clicking on one application out of those applications will get you to the application view where you can see the different connectivities. Each line in here is a connectivity. You can name it. You can say source, destination, service, app ID, user ID, and so on with comments.

And, of course, with the certification status on the right-hand side of the line. And on the upper side, the application is expired, so it's red, and somebody needs to take care of it. Trying to summarize that part, a huge opportunity is in front of us.

Yes, applications can be a pain in the... And there is something difficult to maintain them. But once the right process and application-centric process being adopted, it can work for you. Application connectivity requirements evolve all the time, and the filtering policy needs to keep pace with that. If the process looks at the application connectivity needs at the beginning, you have an application-aware policy and process, and life gets easier. Now I'll do the ultimate webinar risky part, and we'll try to live demo it.

Okay, so that's the obvious magic tool that I mentioned. And we are at the homepage, and there is here a nice list of applications in this tool. I knew it. That's what happens when you try to demo stuff. Let's see if it's coming back shortly. Finger crossed.

Three, two, one. Yes. We've done that. Cool. So you'll see here a list of applications, and you'll see, again, for each one, the status. They can be in draft, or they can be inactive. There are different life cycle stages of an application. And you can see for each application a risk score that would be network risk, and you'll see vulnerability score, and you will see when it was last modified. If that's on firewalls, on cloud, you will see here the type of devices. And let's look at the juicy one. Let's try that.

And that will get us to a view of an application, and you'll see this application wasn't pre-certified lately. You can see some supporting information. You can see tabs that user added to that. You can see here the owner for that. You can see the different connectivity needs of the application. You can see some of them are green. That means the security policy approved them, and some of them block. Probably somebody documented that, but they haven't made sure that it's operating correctly.

And you can build yourself a nice diagram that's being built automatically, but you can play with it around and make sure it's the way you want it to look and so on. And you have the change requests that were issued for this application and by whom, and you can see the exact status of each change request. And you can see vulnerabilities that's connected to vulnerability scanners. It depends on the scanners that you are using, and you can see the score, and you can look at the items in it, and you can see all the information.

Of course, you can see the risk level of the application. We are 100%. That means that we are in good shape, and you can see who's done what with this application and a lot of tools that you can play around with that. And I promised to show you a way to discover an application. So you see in this demo, out of the 11 ways we have to discover an application, I have four connected. Let's look at the importing application that our cloud scanner recognized.

So in AI solution, look at all the tags and different words, textual information that we have in the accounts that we onboarded to the system, the cloud accounts. In that case, we probably look at Azure because everything is Azure here, and you see that I've discovered many applications. And just for the fun, I'll try to import one.

And again, wish me luck. It sometimes takes time. It analyzes all the information and brings all the flaws. And eventually it will be 100% completed. Let's look at one application like that that we've imported.

Okay, it's successful. And you see here that the application was created here. It's still in draft mode. And you see that it was automatically discovered from the cloud. And you see here some cloud-related information, the account, the account provider, the region, and so on. And you can go and look at the application graph. And you see here an application. You see it's all made of cloud elements. And you see here some critical issues that this application has. And you see here that you have Internet access that probably can go directly to this vulnerability.

You can click on it, and you can play with it, and you can start basically removing the risk of your application. You can also have a look at the oversight of all the applications that you have in that account or in the entire public cloud. And you remember I said that you need to prioritize things. So you can see here a good way to prioritize the number of findings, the security issues, if that's connected to the Internet, the number of microservices that you have in this application, and so on and so forth.

For example, you can see that it's connected to the Internet, and it's high risk for open ports, and there is a lot of security issues. Four of them are critical. And the solution automatically marked it for you in the order of the two things, but you can play with that. And I think now it's a good time for pausing. We have some questions.

Well, thank you, Amir. That was really interesting, and I'm sure our audience got as much as I did out of that, and it was really exciting to see where this field is going. So we have some questions, and let me take them one at a time. So the first question we have, how many applications should we expect as a result of an application discovery process? I'll try to take it, Jonathan, with your permission. So we are doing projects like that on a daily basis.

We try to convince all our customers to at least try to discover applications, and that's tricky to talk about a number because you can define an application in different ways. For example, if I have Jira in my security state, and I have a staging environment for that and a production environment for that and a lab for that, maybe it's deployed in three regions. I can decide if everything is one application or if that's three applications because of the three regions or three multiple by production space and so on. So there is like multipliers that you can take here.

Usually, the numbers are running between 1,000 applications for a medium-sized organization to 5,000, 6,000 applications discovered day one. Interesting. Thank you so much. And I think the next question that comes up is an open-ended one. I'm sure the simple answer to this is yes. Are you familiar with big organizations that have adopted the application-centric approach shown here?

I think, yeah, we can both say yes to that one, but perhaps you can give us an idea of the kind of organizations that have adopted that application-centric approach. So we see that European organizations are a little bit ahead of that, and we have many huge European organizations, car manufacturers, furniture manufacturers, banking organizations are going through this process trying to keep their environment tighter and tighter. Another big boost for this adoption of an application-centric approach was this recertification regulation that I've discovered.

I mentioned many organizations that find the recertification work too big and too hard for them, starting adopting that approach. So basically, any organization you can think of that has the right requirements will go for it in those days.

Okay, good. Good. And by the way, while you were talking, I took the liberty of putting up some related research from myself and my colleagues at Kup & Gikol. So for those of you on the webinar and when you receive the slide deck, do feel free to click through those links and check that stuff out.

Also, while I get the next question, I wanted to point out that we have a couple of Identity Fabric days in Munich in September and an identity-centric cybersecurity, which I expect I will be at both of those. So if you want to meet up in person, you know where to find me. That sounded like an invitation to a deck collector, didn't it? The final question that we have up here right now is, when having two teams managing security operations in an organization, the on-prem team and the cloud team, what is the best practice towards policy changes?

And Alfred says, thanks very much for this one, because that must be remarkably common, actually, Amir. And, you know, given that kind of the legacy environment you're transforming, very commonly you see a team that's doing the on-prem thing and a team that's doing the cloud. And you say, well, they are often at loggerheads.

Yeah, how do you deal with that? You know, Jonathan, when she hit the fan, and the CEO is in the news because there was a security breach, he doesn't care about those two teams.

You know, there is a shared responsibility to make the company secure. So, yes, there's like a lot of organization fighting and trying to fusion processes and trying to make sure that it's clear when things go to the on-prem team and when it goes to the cloud team and how to work together with the same guardrails. The nice thing about what we've described here is that an application usually crosses those boundaries of on-prem and cloud. The gas loyalty application, for example, you find the next gas station and pay with the Apple Pay and share information.

It may go from on-prem and cloud and cross all the boundaries that you can think of. And this is mapped correctly in your organization. I've got an interesting example, actually, of this in the country I've moved to. I live in Portugal now, as I may have mentioned. And Portugal is making great strides towards e-government, particularly in citizen services, citizen taxation, and so on, and indeed in healthcare.

And so it's quite common to have an app on the phone which interfaces with central systems, obviously connecting into the cloud-based and then linking into legacy systems in the finances, in the financial offices in the local councils. As you say, there are a number of these places where it's imperative to have a common security policy management framework.

As I say, if we don't, we are literally handing weapons to the attackers. And if the process is centralized about the need, the application, and not looking at the infrastructure, so you have one process, and those teams can collaborate through this process. One process probably would mean one guidelines for how to build a policy, and one approver, and one documentation system.

And yes, the infrastructure may be different, and on-prem will do things, will probably do things in one way, and in the cloud, the DevOps teams will do that. That's all cool, as long as you have one process, and one responsibility, and clear guidelines, and that's the beauty of using application, which fuses those things together. It makes perfect sense to me.

Well, we are coming towards the end of this webinar, and I really enjoyed talking with you and listening to you. One of the great joys of this is how I get a chance to learn a lot from people like you. So thank you very much for your time doing this. Are there any final sort of closing thoughts you want to leave with me and with the audience before we wrap up for the day?

No, I think our message is clear here. Build a good process. Make sure that you look at the intent. The rest will align accordingly. It was fun talking with you too, Jonathan. Thank you very much, Amir, and hopefully we'll do this again soon.

Well, folks, thank you very much for your time. We do try very hard to produce these webinars that we hope are informative, actionable, and obviously help you with your day-to-day cybersecurity and identity challenges. My name is Jonathan Kerr.

I work, obviously, for Cuppinger Coal. Should you wish to get hold of me, you can reach me through Cuppinger Coal. We analyze markets, trends, software solutions. We produce a wide range of research. My particular interests are AI and software supply chain security. We run events and webinars like this, like our flagship EIC event in Berlin, which, if you haven't been, you should go.

And, of course, we have a fully-fledged advisory team that support IT professionals in decision-making processes. Thank you very much for your attention. And if you want to reach me, my email address is on the slide. Thank you.