Turn Zero Trust Into Everyday SAP Reality

Welcome to our KuppingerCole Analysts webinar, Turn Zero Trust Into Everyday SAP Reality. This webinar is supported by Pathlock and speakers today are Clemens Guetter, who is SAP Architect at Pathlock, and me, Martin Kuppinger, I'm Principal Analyst at KuppingerCole Analysts. And this webinar, I believe, will be a quite interesting one because we will look at a variety of themes.

So, what would zero trust mean for SAP and what areas to touch, what to cover, what does it mean from a sort of a security tooling, SAP security tooling perspective? I will bring up maturity level metrics for SAP security across various domains of security, and we will look into many other topics. And one of these is also how can we ensure that code and changes are handled properly and don't cause issues, so that things really also remain secure even in an ever-changing environment. I'll look at the agenda in a minute, but this will be a bit of the flow of today's webinar.

A little bit of housekeeping before we start. Audio control is done automatically, nothing you would have to care about. We will run two polls, one right after the slide, one at the end of my part of the presentation. And I'm always happy when a lot of people participate in the poll. If time allows, if it fits into the flow, we will share results of the polls during the webinar.

Otherwise, we use them for other purposes. There will be a Q&A session at the end of the webinar, so you can enter questions at any time using the control panel. At the lower right bottom, there's an area of questions where you can enter your questions. The more we have, the more lively the Q&A will be. So use the opportunity to raise your questions to me and Clemens. We are recording the webinar, and we will make the slide available soon after the webinar. So before I look at the agenda, there's a first poll that will open, and you can respond to it. You can have a little bit more time.

I'll then continue. And I'm curious about who's responsible for SAP security versus SAP access governance. So governance would be whatever, SAP, GFC access control, pass log, or tools like that. SAP security would be really more the security things from code security to auditing to sort of threat monitoring and response. So is it the same team, or are it different teams, but it's in the same department? Or is this really different departments? Or is it really that a lot different people are involved in security and governance, and it's not really in any means a centralized?

So that's what I'm interested in. I'm looking forward to your responses. This is the opportunity to respond to you.

So agenda, two presentations. I'll talk about Zero Trust and SAP security and compliance. After that, Clemens is going to dive deeper into security application level and looking at custom code and changes, and probably bring in a lot of other information from his experience from the field. And last but not least, we will do a Q&A session. And when we talk about this entire theme, this is a slide I used a couple of times in the past over the years, but I think it's a very important one always to keep in mind when we about this entire thing.

Also, when we talk about conceptual aspects like Zero Trust and what does it mean, compliance is not the same as audit, and it's definitely not the same as security. So compliance means basically we are fulfilling requirements of the laws and regulations. In an audit, we are able to prove that we are doing things where we sort of say we are doing them. An audit will not cover everything. So passing an audit doesn't mean that we are fully compliant. The actions are what we really do. This might be slightly different from what we tell the auditor we are doing. All this is related to each other.

Compliance, an audit, very clearly, the actions as well. But we must not stop here because at the end, the security is what really counts.

Yes, it really counts that we pass the audit, but we don't have regulatory compliance issues. But the key point is neither compliance nor audit make you secure. It's taking the right actions. This might be more than it's asked for in an audit, more than it's a regulatory compliance requirement, especially because a lot of these regulations are still relatively vague in what they request for. So doing the things right is really essential. And I guess the data were an interesting sentence. It was a little easier in Trump.

In the end, it said security will not help you selling one more thing or one more good or worse ever. But security will help you in selling goods because if you have major issues, it might be that you don't sell anything anymore. And this investment absolutely makes sense. And so we have a lot of dimensions then to look at security and compliance where things come together. So we have to business risk and compliance. So what is really the risk to business transactions? The things we are looking at is continuous controls, but also static controls.

Within that, we have that level of how secure is the specific application like a certain SAP instance or other line of business applications and other applications like Office. And then we have the system and the cloud security, which goes into data, which goes into the system and cloud. And we could add the code security, which is probably an element within the application security, but also something that might turn out to be rather specific. For the world of SAP, when you look at GRC, so governance, risk, compliance, it's the one field including the access control elements.

And when you look at security, then we have a relatively complex scenario. So we have specific security for SAP. We have security that beyond SAP that may impact SAP, but goes beyond that. We have the SAP specific types of GRC, meaning the product portfolio name of SAP, but the things we do, which can be from various vendors. And we have things that we need to do outside of SAP.

For other types of line of business applications, for other types of applications holding data, when we take GDPR, then there's a ton of things that happens outside of the SAP realm, because it's about all types of privacy-related data. And so we have different approaches. We can treat everything isolated. We can do it a bit more SAP siloed in a sense of we do things for SAP, and we do things for the broader, so to speak, for the outer space. Or we have more GRC and the security layer.

So the second one, SAP siloed would be, so to speak, the vertical, the other GRC versus security, or we can go into a holistic perspective. But I personally, as someone who is in the identity, in the cybersecurity, and the governance space for decades, and I've seen a ton of organizations, I have a clear tendency towards holistic. So going into integrated approaches that provide you a holistic perspective across everything. It still means you have specialized tools for the depth, but you integrate at the risk management level. You have a consistent view. You can enforce your controls.

You see things beyond that. And I think this is something which aligns very well with zero trust. So zero trust is a concept that's out for a while. It's maybe not as hot anymore as it has been, but I think it's probably even more relevant than it ever has been. The concept is relatively simple to phrase. Don't trust, always verify. So the idea is that you have multiple layers of security, that you have recurring verification, that you don't say, okay, if someone has passed, and this was the starting point, whatever, the firewall, then probably this is good.

And we don't need to care about it anymore. Verify for every access, for everything you do. This recurring thing leads to a multilayer approach. And we can apply this, I think we should apply this to every type of environment, to our entire IT, including SAP. And when I talk about zero trust, my starting point was always, how does this really look like in reality? That someone or something, an identity from an endpoint or a whatever, could be also a server, communicates via the network to a system where applications run on. If you're in the cloud system, applications are somewhat aggregated.

It manages data, it works with data. And this is what we really need to keep in mind. At the end, it's about data. The entire thing, data information, the entire thing is we're in IT information technology, in information security. So we really also need to look at these aspects, what happens there, and that's all built on software. So software is an important element that we need to understand. We can't simply trust software. We also must have processes in place to that not only access is handled properly, but also every type of code change.

And zero trust is something which really encompasses the entire IT. And when we look at this, the identity that's handled with our identity access management, partially maybe in SAP, it could be the CUA, it could be more, it could be third party, whatever. We have endpoint, which is probably a little bit unified endpoint management, endpoint text response, and things like that. We have the network aspects of how do we securely communicate over the network with a variety of technologies.

We have at the system level, when we go into the SAP real, then we have the SAP sort of system level securities, our secures. And what can be done within the application. So one would be really more the configuration for the system, that level, and the other would be really the patch state and all this other stuff. The other would be really more the IAM and access control level, again, what can be done within that.

For data, the business aspect plays a very vital role. It's where continuous controls management comes in. And then also to keep the code secure, we need to look at code and transport security. So zero trust is a universal concept, applicable to everything, links to a variety of tools, some SAP specific, some generic. It's a universal principle we should look at. And what I did is I created a little matrix, which maps these seven layers of zero trust to sort of six stages or layers of SAP security. What I defined here is system security and hardening.

So really that level of system security and threat intelligence and response. So looking at locks, events, et cetera, what's going on there. Code security, then really the change management configuration transport, the identity and access piece, and last and least, the business level process security and control. And what is interesting to see is, for instance, that identity is relevant everywhere, that everything should send signals, information lock, information to threat intelligence and response, that code security is really very specifically to software.

But to an extent, also there's an identity needed for code security. There's something happening at the network level with changes and so on. So there are quite a lot of dependencies and overlaps. And so this, I think, highlights the need for looking at security in a more holistic perspective on one hand, which is the one thing, the other is also it highlights that we need the multi-layered security because various levels impact sort of various or various SAP security layers have an impact on different stations of the zero trust model and vice versa.

So it is essential that we understand that we need to look at it really multi-layered and holistically. And then there's a situation which I think is also very or a reality which is also very important. It is not that this entire thing resides in a sort of in a closed silo. At the end, we are in a situation where when we take these six security layers, then we have this isolated perspective on process security and control, for instance, with the SAP solution or third-party very SAP-specific solution.

But we also have a cross-line of business continuous controls monitoring approach where we say, okay, if whatever suppliers are handled in a third-party application and our invoices are handled in an SAP system, then we need to bring these signals together to understand that, but also to move forward to a signal integration with IT security. So if your deepfake detection and some other maybe security-related signals say, okay, there might be a compromise from a session, then you have a huge 25 million transaction, which you see in your continuous controls monitoring.

If you bring together the signals, you can achieve a very different level of security. We have the identity and access management where we clearly have user management in the SAP realm, and we have other applications. We have authentication that may come from outside where we just trust them.

Configuration transport security is really very specific while, for instance, threat intelligence very frequently then sends signals into other types of applications Again, we are in a situation where we need to, when we look at this entire thing, probably also need to think a little bit broader in the sense of from a zero-trust perspective. First, we need to cover all stages in an SAP environment, which means we have quite a number of solutions. Many of these solutions also are relevant and impact other types of applications. And this is where we need to think beyond just the SAP realm.

And I reflected this also in a, and I don't want to read out this entire next slide, but you have the ability to download a slide to go deeper into that. And I'm also very curious about your feedback, Daniel, which you may send me directly. I created a maturity level metrics for SAP security where I look at, again, these six layers and the second row is just a description of the five levels. This is following the CMMI approach, this very established approach on maturity metrics.

And what I think is very important is that to that definition, the higher levels of security, and this in the sense are also the ones who are better from a real security, from a real risk mitigation perspective, but also from sort of delivering or paying into the zero-trust model, they are always tending towards an integrated approach where in many cases, the signals are integrated with more enterprise-wide situation.

I think when you take strength intelligence, learning about things from other types of solutions, from your XDR system, which one is for the entire IT and say, okay, here are certain things going wrong, which may impact the SAP system. It's very essential as well as delivering SAP-related signals into your XDR, for instance, or behavioral analytics, the identity and access management law, so how is access used across multiple systems, can deliver broader insights and increases the security beyond trust and isolated approach.

So that is something I personally believe strongly in, that we need to look at the heterogeneous reality of our IT. So the challenge is all this is happening in an agile IT environment, and what we need is really automation here to make it work. So I talked about holistic integrated, and another element is we need to automate because things are moving faster than ever, and that won't change anymore. We have more scale, more change, more agility, and so we need to look at it integrated at various levels beyond the SAP, but also integrate within the security and governance perspective.

So we must not isolate SAP security from SAP governance, but look at all, and this I think becomes very visible when we look at the zero trust picture again, which really has multiple levels, multiple stages, and all of these must be covered, and then it's about having both security and governance. We need change management like code control. This is something we will elaborate on in the second part of this webinar. So how to handle that, and it's not only code, it's configuration changes, it's everything which tends to change.

We need to make this work across everything, handle it properly, and we need to automate. This is especially important for the monitoring observability. Observability is something which means we monitor, we have the visibility, but we also can take actions, we can also automate actions across the stack to react quickly, and across the stack is important. What I find, and this is maybe just a little bit food for thought, is an inference.

We have, according to numbers, and they might be a little higher or lower, there are quite a number of SAP customer organizations globally. This includes success factors and all the other sort of non-ECC and goodness types of customers.

Let me, for instance, look at access control vendors that are really product vendors, that not just have a lot of consulting-derived little tool, but they really sell a product, they have a product management, they have a defined product development, the versioning, and regular updates, stuff on hand, that are only relatively few. For SAP security, there's a bit of a broader portfolio.

Again, looking at product vendors, there are maybe even less. Out there for automation, also not many.

Yes, in some areas, there are tools for SAP, which is then one of the vendors, but what I find interesting is to see that the built-in tooling has limitations, but I think we really need to spend more thinking and more investments for the entire security, governance, identity, whatever, for this SAP real and beyond, in an integrated perspective, across all these aspects of zero trust, because we need to secure multi-layered security for our entire IT.

SAP is a very important element that we need to secure properly across everything, but that also means we need to understand if something in the outer space happens, what does it mean, and the other way around. With that, a quick second poll, which is going back to the application access control, so the access control aspects for the line of business applications, SAP and all the others you may have, like Workday, whatever else, Salesforce, and so on. Are these different departments per application? Is it the SAP department for everything? Is it the identity management department?

I'll release the poll open again for a bit, and with that, I hand over to Clemens Gittler, who right now is presenting his part. Clemens, it's your turn.

Thank you, Martin. Clemens Gittler, my name. I'm from Germany, and I am SAP architect and product from product management. I lead our cybersecurity department, and I'm not as long decades in this area, but a decade, I already have something to do with development and monitoring solutions, and it's my pleasure to bring some insights into daily business, into real-world problems, and into the back from theory, right, into the real world. I divided my slides and also my whole presentation into two parts.

The first part is dealing about, let's say, the standard about custom code and transporting in SAP layers, which is obviously the way how SAP delivers things. Let's make it a little bit abstract. Between a development system, for example, a production system, this is the first part. I think most of you, or at least most of you who are a little bit deep into SAP, will deal with this day by day.

On the other hand side, we had the chance to get in touch with one of the biggest software and cell phones companies of the world, and developed in a joint venture, or directly together, a continuous compliance tool, which is then, if you go back to your matrix, way more into real-time code and change management control for security and access governance teams. Let me start with the first part. I just want to say something about why we need solutions. It's for sure not an option, if you ask me at least, because SAP systems are the one hand side only as secure as the custom code.

Number says that 50% of all breaches are based on internal, hackers, internal backdoors, internal problems. A lot of them are accidentally done. Someone has not followed principles. Someone didn't understand what he was doing, forgot about authority checks, did dynamic call statements, for example.

Also, some of them are forced. We will come in the next slide into one example we identified in one of our customer's landscapes. I took it as my go-to example, because it's so easy and so interesting to know how easy it is to get access to a system where you didn't have access before. Back also to your ignorance slide, you said SAP standard tools are good, but the problem is they are not focusing on security and compliance. They are more focused on the operations. They are more focused on getting things done, on completeness, and so on. Those big picture is missing.

You need someone who is understanding, for example, transport, who is understanding custom code, who is understanding everything around and has enough time. I think every one of you can relate. There are experts in each company which understand everything, but they have never time. This combination is why it's so important to have some tool supporting you.

Otherwise, it's not really possible anymore. What was the problem?

2020, the company had a little breach. It was an energy company in US. What was the problem? A developer wanted to have access to a production system because no user available. He created a report, which is creating a user, which is giving it a standard password, and he added it into a transport with an expert, so-called. An expert is a program which is automatically executed after the transport is done. There are reasons, for example, if you need to migrate some data, so the flow is working, and so on, that these experts are needed.

The functionality is given by SAP, but it's very, very critical if you are not careful. What happened? The transport passed SAP standard checks because they are not focusing on security level, and the user was exploited, had access to financial data. It was not really traceable because no one was looking into a client-triple-zeros-of-all problem. Root cause was, okay, there are multiple root cause, but since we are talking about code security, the real problem is custom code and transport logic was not enforced.

This is also what I will show you after one slide, how SAP standard checks are reacting on my breach report, and how our tool reacts, and what happens if you import everything. I will focus here in a second on the SAP GUI level, because it's the fastest way to show everything. For a more detailed thing, we have also everything in dashboards, but I don't want to bother too much. To give first and short takeaway before I go into this demo, SAP standard then you have custom code in field of code scanning and transport control.

Otherwise, if they don't work hand-in-hand, you cannot handle all the code is done. For example, for the one customer, we have the joint venture I mentioned at the beginning. They have more than 10,000 custom transactions they are working with, and it's just too much to make it manually with the resources they have. Let me go to my demo. SAP GUI. I don't want to bother you too much with coding and so on, but I want to show you it's only 30 lines of code. It's not really much, but there are two function calls which are really critical.

This is this barbie call of user create, because it's creating a user, and the barbie call of user profiles, because it's designing SAP all SAP new. For everyone who is not too deep into this topic, okay, user create is obvious, but SAP all SAP new are the two profiles in SAP, which gives you access to everything. The next problem is client triple zero in an SAP system is a client which is always available, and they are all development objects are stored, et cetera. If you have full access to client triple zero, you have effectively full access to the whole system.

Now, let me show what happens if you use the built-in SAP ATAC default variant. A lot of companies I know are working with ATAC, because it's easy to use. All ABAP developer knows how to use it, and it's just convenient. What happens is, with default variant, that my system is a little bit slow, I only get one prior one and one prior three finding. The prior three finding is just about the text element, so it's a text which is not translated. It's actually my password, because password is obviously not translated, but it's just prior three.

It's an information warning, and the critical part is only informal parameter does not match. If I look here, it means one of these three variables are not matching the right type. If I come to you as a transport administrator, I can always justify, because of reason X, Y, Z, I need this, and this makes sense. It will not dump, I promise you. If you don't look deep into it, you will not identify what the issue is. I can show you now the path log to speed up a little bit. What happens, you will see other things, because we don't focus too much on the syntax part.

We don't care if it's failing, because the type is not correct. We are focusing on the security part. We have an hard-coded password, obviously, because I added a password, and we have this creation and assigning of profiles. Additionally, there are some access violations, which are compliance problems, but I want to focus on this create and assign, so we know we have an issue. If I now go to my transport, I prepared, and I release it, I have not activated any transport controlling right now on the system. It will just go through.

There's nothing, because SAP has no out-of-the-box export controlling, which makes any checks on the system. If I go now into my next system, my test system, into the import queue, we don't have automatic import, but I can just go into the import queue and look into it. I will see it's just my transport I released right now. If I try now to import it, I think I can just go like this.

Yes, I want to go. It would have been imported if I not have activated the transport blocking.

Here, we are a little bit limited with the outbound, but transport is blocked. Let me go to transport control for a second, so I can show you what is the reason of it. We have our dashboard. We have also a web dashboard, but again, just to make it fast.

We say, okay, we found something. We identify the autostart report as an issue. We identify the code problems as an issue, and especially these code problems are here. Both are actually the problem.

Now, you have the chance to look into it, because you work with zero trust, and you can follow on this issue if you need somehow to transport it, because you need access to system, whatever. Surely, you have options, but then you follow the zero trust approach. This is the important part. My second part now, I want to show you what I mean with the continuous compliance. With our latest product, we developed the application profiler. The idea is that manual compliance checks are problematic, especially if you have just too many custom code.

There's too many custom processes, just too many changes, et cetera. What is the problem? If you have a transaction, this transaction points onto a report or a program. This points to whatever. It's just too much to follow. The customer, we developed it together, has especially two challenges. We thought, or we know this is a challenge all companies have. The first challenge is their SOD team needs to understand what happens. Are there any database layers? The SOD team needs to know this on the one hand side to understand, is there a risk in this transaction, in this application?

On the other hand side, the security team also needs to know things like this. Their security team is also responsible for SU24 values, means maintaining the correct authorization values for any role management things and so on. They need to know at the end what is an application doing, at least on a technical and semi-technical level. If they don't know what it means, they can always ask the developer, but they need it as a compliance criteria. When they identify any new object, they need to approve it once. Without this approval, it's not allowed to transport.

Also, the developer needs to fill a questionnaire and to explain what it is, et cetera. And so you have already a first identity, what happened to this application. On the next level, the team needs to check differences since last time they checked it. They can identify if someone deleted an authorization, if something is added, but no additional authorization was done. And so this is the whole project behind it.

What you can do then is you scan the transport to uncover everything which is in this application and you identify things and so on, but I will just show what I did with my second transport. Here, I have a transport which only contains one transaction. Because it's the entry point, this transaction is actually showing on this program to make it easy. I don't show you a second point, but if I release it now or try to release, our application profiler comes in. And if I try to release, it's blocked because the transaction is not approved yet and I cannot approve it.

Since I'm now the developer, I need to fulfill the questionnaire. I need to explain what I have done in this application and I can now have the questionnaire here. Not really a sharing window about what I have done. I'm done with something and I did it. Now I can submit the questionnaire. At the moment when I submit the questionnaire, this application is analyzed, is scanned and the team behind knows now what happened inside. I will show you in one second. For information, I have all walls here to make it easier to find everything.

We have now here an approver inbox and you can find here all items. I personally am not maintained as approver. Even if I have sub all, I can't handle it. This is what I want to show you here. I can see it's open. It needs to be approved. You see what is the next team. It's team one. Let me just close it once again to show you this. We have also a conditional because it was transport blocked. You know already as an operator, this has a little bit priority. Now you can go into the dashboard.

You see the most important information, the questionnaire, but the most important part is this event block. We have here different categories where you find events. In this case, because as I said, I'm just focusing on the same report here to make it easier.

You see, it's this two popular calls. If you're from a security team, you know it's very critical. You can see where it was called and see into it. You can review everything. At the end, you can approve if you are part of the team. If you are not maintained as approver, even if sub all does not help you, you can't approve it. With this said, I want to go back to my slides. The important part here is really that you always know what has been changed in an application. For the customer we developed it together with, they only want to check it once at the beginning.

For updates, they don't want to look. They review it, but they don't want to have transport blocks anymore. This is a can identify security issues. You can identify SOD violations. You can divide it between different teams, as the poll at the beginning was mentioned. What is the goal of it? Even with the 10,000 applications the customer has, it's handleable with only two teams. There are two teams, each have less than five members. To identify in real time, because a scan takes one to 10 seconds, you get all the information using this data mode.

You also get all information, including only what has been changed since the last time. Because of the time, I cannot show the full insight, but the idea is that security and IT is always aligned. We only want to have transparency, so we can enforce a zero trust principle, but not give you the full picture, so you can understand what is going on, what are the next steps, et cetera. I want to thank you all and give it back to Steve.

Yes, thank you very much. I think we walked through quite a number of aspects. What I want to do next is move into the Q&A session. We have a few questions here.

Again, be asked. If you have further questions, please send them in. I think the first question I'd like to start with is a question about ... You called this to a certain extent, and I think it might be worth to rephrase and pick it up again a bit.

That is, if someone already uses SAP's code inspector and ATC, so the ABAP test code split, then do they really need an additional tool for code scanning? I would say, latest done, when it's not just ABAP code, anyway. I think you discussed this. Maybe you can put together the main ...

Yes, sure. SAP code inspector, or SAP ATC, it's just a framework based on SAP code inspector. They are really tied together. It means more or less the same to start here.

SAP, unfortunately, only starts with the developer tool code scanning. What we want to elaborate is the security tool code scanning. We also have tools, but it's not part of today's session for the security team, for compliance team, to see the holistic approach you mentioned before, and not only the coder, the developer. Since we are from the security perspective, I need to absolutely say, yes, you need something else than ATC, because from a security point of view, you have no chance to show everything, to see everything, and to have this zero trust enforced.

Okay, got it. Another question also, probably one that you can answer best is, can Pathlog integrate with existing change management process and probably also change management tools, which may be in place, or would this require reworking DevOps pipeline?

Again, I think it's something which is of interest for two scenarios. The one is really the ABAP scenario. The other is the scenario where you also use other types of code in the broad realm. What's the Pathlog approach on that? Maybe to start with the classical approach. For example, if you use a charm, I think a lot of companies are still using charm processes.

Yes, this works out of the box, everything. We have also customer third-party tools. We are happy that it's working for sure, and you only need to look how is the integration level. Maybe you need to jump into our dashboards. Sometimes it's also possible to integrate it directly. It depends a little bit from what we have, but it's working for sure. This is the most important part. Since you gave me the ball already two times and I ignored it the first time, what is with non-ABAP? ABAP is one hand side. We also support Fiori, but we are on SAP infrastructure right now.

It's more or less Fiori, JavaScript, and ABAP. For change management, it's also required more and more companies go to GitHub, for example. We have now our GitHub connection. We also give you possibilities to use Jenkins, for example, pipeline, which is way more modern and not so often used in SAP directly, but close to SAP. This is also supported. I don't think you need to change your pipeline, and this, I think, is a good part.

Okay, great. Another question for our final question, unless further questions come from the audience. It goes also back to your presentation demo. You mentioned profiling changes in real time. What kind of insights can security teams actually see before a customer application goes live?

Yes, this is back to the second part of my presentation of the application profiler. Currently, we support two big parts first of changes, which are part is on the one hand side, let's say, hot things like you have an RFC functionality, you have database operations, you call this bar piece, like this user create and user profile, and all this coding parts, this hard coding part where informations are somehow covered. This is on the one hand side, and the other hand side for security teams also very important is all authorizations, which are somehow needed.

This is used to give you a perfect overview about the authorization needed to build the roles, but also to check if the authorization matches what the application is doing. This can be done in real time, again, like 10 seconds delay, maybe. It depends a little bit how your background processes are actually, but especially the first time things, it's like a 10 seconds delay.

For SAP, it's actually real time. Yeah.

Okay, great. Clemens, I think with that, we're done with the questions. Thank you very much for all your insights, which I believe are very deep and very helpful. Thank you. Thank you to PathLab for supporting this Google Analysts webinar, and thank you for everyone who was attending this webinar. I hope you got some interesting insights from this webinar. Thank you very much, and try to remain on for today.