Bridging the Gap: Achieving Compliance and Application Security in SAP Environments

Welcome to our KuppingerCole Analysts webinar, Bridging the Gap, Achieving Compliance and Application Security in SAP Environments. The speakers today are Jonathan Stross from Pathlock. He's an SAP Security Analyst at KuppingerCole Analysts. So welcome to this webinar. And in the next, well, a little less than an hour, probably, we'll go a bit into detail around how to bring together all these different areas and requirements, like security for SAP, Share-C. So having said this, I'd like to do a little bit of housekeeping here first.

So audio, nothing to do from your end. Polls, we will run two polls throughout the webinar, one right after the slide. And I'd be happy if you take part in these polls. We'll have a Q&A session at the end of the webinar. But you can enter questions at any time. There's an area chat and an area questions.

Ideally, you put your questions into the questions section because this is where we will look at for the Q&A. So the more questions, the more likely the Q&A will be. And last but least, we are recording the webinar. And we'll make available the recording as well as the slide for the next in the coming days. Having said this, we directly will launch the first poll. The poll will stay open for a bit. So you can participate at any time. You'll find a poll as well on the right-hand side of the section with chat questions, et cetera.

So the question here is for, let's say, application access control for all the things around access entitlements, SODs, critical entitlements, and all that stuff. So controlling that, who is responsible for that across your line of business LLB applications? So are there different departments for different applications? Is it the SAP department, for instance, because you're primarily an SAP shop? Is it the IAM department, which looks at all the access aspects, the identity and access management department? Or are it others? So as I said, I'm looking forward to having you responding to the poll.

The more people respond, the more interesting it is. And if time allows, we will look at the results of the poll in our Q&A session.

For now, I will talk a bit about compliance and or versus security in SAP environments. So looking a bit more at a broader perspective of the entire theme here. The second part, then, Trommelson will talk about from misconfigurations to compliance issues and how to fix these. So what does it really mean? How do these things like misconfigurations, concrete security issues, compliance issues relate to each other and how to deal with that? This is also a way more from practice than my more generic talk. And as I said, then, we will go into the Q&A right after that.

So when I go to the next slide, I want to start a bit with something I created quite a while ago. And I think it's very important for this entire scene and beyond that, also for practice to keep it in mind. And that is about compliance. That's not equal audit. That's not equal security. And we need to do things right. So compliance basically is our ability to fulfill the requirements of laws and regulations. If we can fulfill these requirements, we are formally compliant, which is a bit different than an audit. An audit basically means that we are able to prove certain things.

So when we are saying, we do this and this and we fulfill this, then we must be able to prove it, which can be sometimes not exactly the reality. It could be just that we are able to prove the right thing, which is asked for by the auditors. So compliance, not necessarily, is exactly equal to passing an audit. Because an audit is very much a snapshot, looking at certain aspects of it. While actions are that what we are factually doing. So actions is really what are we doing. What are we doing in practice in the security configuration and the access management and all the other areas.

And it's clearly not exactly always what we are telling to the auditor. But all these things are related. So compliance, audit, actions are related. And what we can't do on the other side is we can't stop with just saying, OK, we want to be compliant and pass an audit. That's not sufficient. Because that doesn't mean that we really will be secure. So being compliant, passing an audit doesn't mean that you're secure. Only if you take the right actions, you will be secure.

And I think this is very important, because it also means that we should look at the GRC aspect on one hand, where we have the governance and the compliance element and the risk element. So governance and compliance are probably more what I have on this slide on the lower sector while risk management and especially risk mitigation can go far more into the security area. This security is the other side of it. And what I feel could be helpful is to look at dimensions of security and compliance and then dig a bit deeper on what does it mean for SAP and how does it help.

So if we want to mitigate the business risks, which is really complex, mitigating risks, there are a lot of things to do in achieving compliance, which is not necessarily simple, but simpler. Then we still have a lot of different dimensions to look at. So business risk and compliance, this is where we look at continuous controls like monitoring our processes, looking at how there are things going on which are at least suspicious, which can be malicious.

Also having static controls where we say, OK, what is the state where we ask the managers regularly about things, the state of whatever projects, the state of certain other things. So this is what we do at a business risk and compliance in a business context, understanding what does it mean to the business. We have the application security level when we look at our primary line of business and business applications, which we do for SAP and other line of business applications.

But at the end, also for other applications like Office where we share information and where we also need to look at, are we secure enough? What do we do here? And then we have the system and cloud security, which is about data. So there's clearly a blurring line between the application security in SAP and other applications, the concrete data security, which is very closely related, as well as the system and cloud security. So we have different layers. And to be secure and then factually mitigate business risks, we need to look at all layers.

So it's not that we can just say, OK, compliance asks for certain things. In financial applications, we need to fix. That doesn't mean that we successfully have mitigated our risks. We can only mitigate our business risks if we take a broader perspective across all of these layers. And that is also why I feel that we should always look at security and compliance in an integrated or in a holistic manner. And so one of the questions we need to look at, and that is basically the key thing for this webinar, clearly is what we mean for the world of SAP and beyond.

When we look at the GRC aspects and security aspects. And so I created this picture of GRC on top, security at the bottom, SAP on the right-hand side, non-SAP on the left-hand side. We focus more overall on the business applications. But at the end, when we look at security, and those are some aspects of GRC probably beyond the line of business applications world. And so how can we address this? We can address this very isolated. So what is not uncommon? We have whatever SAP access controller, most still talk about SAP GRC in place of SAP Cloud IAG.

And we have whatever separate tools for other line of business applications like Oracle, et cetera. We have maybe some specialized SAP security tools in place or just utilize built-in technology. And we have quite a number of non-SAP security tools in place.

So a rather diverse approach, which is in that type of, sorry, these scenarios, what I observe is that this is a very frequently quite tools-focused and sort of domains-focused, where only certain aspects are covered, frequently just enough to pass, certain audits, but not necessarily is to focus on how can you really successfully mitigate the business risk. We can do it a bit different. We can do it, and also that is not uncommon. We can do it SAP siloed, I would call it, where we do it for SAP in a combined approach, GRC and SAP security.

Some of the solutions in the market cover both, but still it can be different solutions. Also, when you have a sort of a strong SAP organizational unit, which does things for SAP, then it's really not uncommon. While we then do separate things for non-SAP applications, if we do it hopefully, we do other things for non-SAP security. And then we could also look at it from a perspective of where we say we have a holistic GRC approach, while we do security a bit separately.

So one sort of at least integration of GRC, maybe a combined GRC solution, there might be a gap of understanding the security impact in that case. We can also integrate this, but that would be a bit more of a holistic picture on saying, how can we integrate it? And still it means that we need to integrate on several tools, because there's not the one tool that helps us to solve everything. Some tools help us to address quite a number of these aspects, but it clearly will require that we have more tools.

And the integration then happens at the risk management level, where we say, OK, we have some risk management layer on top where we bring the various things together. That would be my way to look at it. I personally think what is very important is that we go away a bit from a very isolated approach towards more integrated approaches, where the sub-style of the GRC versus security approach, but both could be valid interim steps towards something where we have a common perspective for the risk posture across the variety of systems, as well as the security.

And the risk posture basically is based on a governance and compliance, passing the audit perspective as well. So very concrete technical security analysis. On the top is, so GRC also includes more the access and SOD aspects, but technical security, like system configurations and many, many other things, that are at a low level below. And over time, we should move to something that helps us understanding what is the real concrete security risk, what are the things that are happening, how can we tackle them across the entire landscape?

Because attacks rarely are happening only towards one single system. They usually come in through the network, pass servers, go into application systems, et cetera, may impact databases. So they are complex. They're spanning multiple areas. That's why we need a more integrated perspective. So before we come back to the agenda, a second poll. And that is more to focus on application and system security. So the first one works really on access controls. This one is really more the security perspective of it.

So who is responsible for the more technical security aspects, so to speak, below the access entitlement, SOD level? Again, same options, different departments, SAP department. I'm handing over right now to Jonathan. And Jonathan will talk about. As mentioned, we're going to talk a little bit about the correspondence between misconfigurations and compliance issues.

And then, yeah, giving you some examples, some steps to action on how, out of a practitioner perspective, you could get started with this particular topic. So as already mentioned, oftentimes, what's a misconception is either you do, of course, security due to compliance, or you do security for security purposes. At the end, also, we as practitioners need to think about what is the common goal. We should rethink about it's all about a digitalized business process.

And we want to safeguard this particular business process to the best ability without disrupting it, making it inefficient, and nevertheless, introducing some kind of controls to operate in a manner where this cannot be exploited. There's a fine border between those two. And especially, what's important to understand is that security alone, of course, doesn't make you compliant. And on the other hand side, compliance alone also doesn't make you secure.

If we imagine an SAP system or any kind of IT system with strong technical controls in place, like multi-factor authentication, role-based access control, strong encrypted data both at rest and at transit, if on the process side, who has access to this very data, to those critical systems, is not enforced, regulated, reviewed, then, of course, you have strong technical controls. But your process controls are not really good. And therefore, the technical security, of course, does not make you compliant. This is a vice versa, as mentioned.

On the other hand side, if you pass SOCKS audits, your user access were controlled, your financials were controlled, your financial reporting, securitization of duties to some extent.

However, typically, we see that, or example here, if a firewall is open to a port, which was sadly out of scope or a zero day whatsoever, so the technical aspect of securing the system wasn't really deepened down and enforced or shined a light on, then, of course, you can still disrupt the business process, disrupting the business transaction from happening, resulting, of course, then, in the system being compromised to whatever extent. Could be just the business process stops. Could be steal of data whatsoever. So it's really what you would need to do is achieve security and compliance.

Also, again, shout out to Martin. I really like your very first slide with the process because that really hits the nail. It's really important to, on the one hand side, enforce security controls and also prove compliance. And what's important to understand here, security protects the system and compliance protects your accountability. So having both streamlined is actually an interest of both.

If we look at compliance regulations, at, for example, GDPR, at PCI DSS, at SOCKS, then we see that there are, well, the definition to have something in place, so appropriate technical measures, secure system configurations, and adequate internal controls. And it's also, to some extent, of course, clear how you can achieve that. So what you must implement is hardening requirements from the vendors. Every IT vendor, I would say, I know, Microsoft, Oracle, SUSE Linux, or also SAP, provides out-of-the-box documentation on how to configure the system securely.

Databases, Microsoft has a great, great database about security configurations of their database. So the question remains here, if those things are here, where actually resides the issue? Why is there, in general, in the market, an issue? And that is actually what already Martin pinpointed, the issue that, on the one hand side, we do have, especially in the SAP realms, a so-called silo.

We see, and it's slowly but steadily breaking up, that the siloed SAP security is now being broken up to become more integrated in the holistic approach of cybersecurity or IT security in the company, which is actually also one of our core recommendations. SAP does have some own lingo. We call it sometimes SAPanese, which is not always very clear to the wider security audience. Why?

Typically, a basis administrator, SAP basis administrator does not sit on the weekend in the office reviewing the security audit log, for example. Here, the holistic approach, forwarding this to the SOC center, which has 24-7 coverage alerting, that makes sense, nevertheless. There is some terminology issues, you could say, between those SOC centers, the holistic IT security, and the homegrown SAP structures. So security teams tend to often treat SAP as their own business unit, someone else's problem.

Therefore, the risk assessment often evaluates either only the infrastructure layer and not then the business process as such. On the other hand side, the compliance addresses the business process, but not the technical side of it. So a database admin, for example, can, of course, also release a purchase order, despite not having the authorizations within the SAP system. And that's why we see a certain blind spot in the evaluation of compliance and security, especially with SAP or ERP systems.

So as an example, the SAP concept, ST code access to SE 16, that means, on the one hand side, a direct data access, if you would translate it to a non-SAP lingo. So we're talking here about a potential confidentiality breach. No logging in SM20.

SM20, well, audit rate. So here, we actually have them report logging non-repudiation risk. And whenever SAP risks are expressed clear, when we help the translation, building the bridge between the SAP native lingo to more common terms, it does make sense, of course, to find a common language, a common structure, how to define and say, OK, well, that is, of course, something which has to do with confidentiality.

Here, for example, is a privilege escalation or initial access. Assignation of SAP all.

Of course, you can somehow, with SAP all, think about, OK, SAP all is route-like access. But there are also other roles and profiles where it's not very clear if you just alert it to the SOC center, for example.

And here, as mentioned, it does make sense to introduce a common understanding, a common language everyone understands and agrees on, to build, then, actually, the enterprise resilience. For example, if we talk about configuration, what we do oftentimes is mapping, actually, the corresponding SAP security-related parameters to this YANA PS principles. So what is being affected if this profile parameter, for example, which greater good is affected? Confidentiality, integrity, authenticity, non-repudiation, authenticity.

There, we map. And we can then say, OK, well, that can be forwarded to a ticket system, for example. Or in general, we can define a process where we can say, OK, also the IT admins know now what is here the issue. And it also makes it very easy, understandable for CISOs, compliance officers, and business stakeholders in general. If we talk a little bit more about the correct modeling part, where it's a little bit more interactive, you could say, red teaming, blue teaming, there, of course, Mitre ATT&CK, for example, does make sense.

So everyone knows user buffer modification is a privilege escalation, actually. A callback execution of BAPI user create, well, also, with a little bit of fantasy, you can, of course, resemble what BAPI user create does. But it could be also a different function module, which has been called.

And here, the Mitre ATT&CK assigns clearly this is a privilege escalation. So today, we're going to focus a little bit about the Ciano PS principles. And you can understand it like the base foundation, then, in the communication of security and compliance to build your enterprise resilience. So you can understand security and compliance as the engines that turn those principles into protection. As an example, I'm not going to go over all the particular areas. But confidentiality, quite clear, protecting sensitive data from leaks and unauthorized access, that is very important.

Doesn't matter which, of course, compliance regulation. But it also has, of course, technical security aspects where you need to enforce, for example, encryption of databases. So on the one hand side, you need to do some process-related, who has access, for example, also to that data, and then with authentication, but also that the data as such is secure.

And here, you can map to the different principles and say, OK, everyone that knows clearly who or what we are talking about, also regarding the compliance perspective. It also has another neat feature. If you take the approach from this particular angle with the corresponding language you aligned on, it will also make the audit test easier, as you can then say, OK, all confidentiality-related checks we do, we can list them.

Here, you see this is actually everything regarding to confidentiality, integrity, availability, so on and so forth. And you can see that all aspects about cybersecurity or bottom principles of security are being met. And therefore, then we are, to a certain extent, compliant. Because you can also map these, of course, then to different areas. And important to understand, especially with an SAP, we do face here and there some common misconceptions regarding then the security and the compliance aspect. On the one hand side, commonly thought, SAP is secure by default. That's a security issue.

It affects confidentiality and integrity, which, of course, affects, for example, the GDPR or SOX compliance. SAP needs, per default, active harmony. SAP is doing a tremendous job in sharing out-of-the-box content to secure your SAP systems. On the other hand side, good security automatically means that SOX compliance has been enforced well. That is not 100% the case.

Here, we really also need to not only secure profile parameters, technical things, we also need to see that the business process, as such, is secure. And therefore, touch the compliance aspect. So the question is, how can we build, actually, the bridge between those particular topics? So I 100% agree with Martin. We should strive for a holistic approach in SAP security. And there's a common, or there's, in general, an issue. As an example, I used to play soccer. And I played, actually, on every position.

But that, actually, had the issue that on none of our positions, I was getting really good. So I was not the one-fit-all solution. And chances are also quite high, especially when we talk about compliance and security, that there is not a one-fits-all solution. We should think IT security as holistic approach, streamlining the corporate IT security. Doesn't matter which app. Doesn't matter which system. To have a risk, a holistic approach to addressing those risks. On one hand, you will, of course, have your subject matter experts in each and every area.

But we need to see how we can do this holistic approach, measuring then, actually, also the success of the security and compliance project. There are a lot of tools around, good tools, which, actually, can help you doing that. Automatically scanning your ERP apps. Automatically scanning your infrastructure, for example. And all those can, actually, also, I would say 90% of those can forward this information in a standardized format to a ticketing system, to a dashboard, for example. And they are utilizing such kind of tools.

You can, on the first-hand side, automate the continuous vulnerability and risk monitoring. That comes in handy, actually, when you have auditors. Internal auditors are here. I have my automated scans. That is a part of the equation.

Now, the auditor can focus on what is not automatable, and therefore, reduce the time and increase efficiency. On the other hand side, we can then maintain, also, with those tools, access to those reports, grant audit visibility.

And, of course, with this automation, you can also introduce the vendor hardening requirements, strengthening, especially here, the SAP configuration against misconfiguration breaches, according to the vendor requirements. Maybe, also, tools like our cybersecurity application controls already do a little bit more than, actually, the out-of-the-box rule set. Would also increase, then, your security posture.

And then, of course, really important, increase the visibility across systems. Must not only be SAP, but the CISO needs, actually, of course, insights into every system, and needs to see that his concept, his experts, are doing the job precisely.

If you build this web, this strategy, this holistic strategy, and, for example, now include SAP and other ERP apps, or endpoint detection, so on and so forth, into the overall IT security strategy, once translated, ZAP risks, or, in general, ERP risks, can be, also, judged in the same manner as technical, let's say, Active Directory malconfigurations, because exploited, they can result, also, in a complete takeover. Either an SAP system is the prime target, or used as a loophole to get into the IT environment.

And, therefore, it needs, also, to be classified the same as an out-of-the-risk perspective, or, of course, with context, like an Active Directory exploit. So, here, in the overall cybersecurity strategy, our recommendation is to not treat SAP differently, integrate it into the overall silo, streamlining the information, the KPIs, use common dashboards, having a unified access governance, and then, also, include the overall corporate threat modeling to include SAP in the overall corporate threat modeling.

It's very interesting what can be done, actually, by red teams once they get a hold of an SAP system, which is not really good configured. And, ultimately, you can then, also, same as in other applications, enable continuous monitoring in the systems, integrating the logs into the XEM, for example, do continuous controls monitoring to see how effective my controls, also, are, and this across the entire landscape of your IT department.

So, summarizing, we strongly agree with the presented approach by Martin. We do see that, nowadays, the SAP landscape is breaking up into, also, different technologies, which require, actually, the risk perspective, or the security perspective, to switch to a holistic approach.

So, we have a holistic approach to cybersecurity, because, then, also, working in this big team, we can share, also, their experiences. With that, we reach the end of our presentation. We already have a couple of questions here, and so, if you have further questions, the first question is, I think that's an interesting question to ask, because I think we both, Jonathan and me, observed the market more. The first question would be, and maybe I start a live answer, here. What I see is that we see a lot of people talking about risks in a lot of different languages.

So, it's probably a bit more of a Babylonic thing happening here, sort of Babel Tower language chaos thing we need to be aware of. At least, I don't see sufficient, sufficient organizations to really bring these things together. I think we need to work on that to really understand what risk means.

So, maybe, Jonathan, anything from your perspective to ask? Practical example. Especially when we talk about logging, for example. One very big topic, which is really, really important to distinguish, then, actually, also, valid access from invalid access from potential exploits happening, actually, in the system.

Here, we see that, of course, in the logging, there is no common format, for example. And here, it's really important when we talk about, especially then, change documents, for example, where we are forwarding this particular data or just out of a risk perspective, trying to address malicious changes.

So, as mentioned, the database admin, who is then changing, for example, a vendor account to his own IBAN or his own bank account. Then, to find a way how we can actually integrate this in an understandable format for alerting and containment to happen rapidly. We see that we typically have, especially in the SAP space, a lot of experts, but the experts tend to not work on Saturdays or Sundays.

And here, it would make sense to introduce, of course, then, a lot of this perspective, a standardized format, understanding how can a successful ROC call, for example, be classified in certain areas, how also an SOC team member would understand. Data loss prevention case, privilege escalation, or something equal. And that's also something where we see also the SAP per default opens up tremendously and enables also such kind of out-of-the-box features.

Okay, great. I think that that is a good point. By the way, just as a side note, I also have been playing football, so in Europe, or soccer. I only mainly played one position. I never was good anyway, even while I stuck to one position. But I was a very typical, classical, let's say, right-wing defender, which either got the ball or the other player.

So, one of the two. So, as I said, very traditional right-wing defender. That was my position. That's actually a very good analogy, because on the other side around, we also have, especially when we talk about defenders, which are, of course, very known for maybe not being the best with the ball as such, but against the ball, very, very good, tackling, so on and so forth. That's also our risk perspective, very applicable to an SAP system, operating into a holistic manner, of course. We need to define also and talk to the stakeholders what an appropriate response would also be.

So, having fail-safes, for example. What happens if now midfield loses the ball and now the defender has to go in? And typically, IT systems or companies are very, very mature when it comes to endpoint detection, when antivirus, but interestingly enough, especially in ERP systems, this tends to stop, for example. An illegal, for example, business process.

So, someone did acquire privilege, escalated privileges, and piped in or through a backdoor of a custom report, for example, an illegal payment. The red team kind of stops there. The red team is typically really about bits and bytes, and I would say every layer below the application layer.

And sadly, that stops at the application layer, but it shouldn't, because especially with privilege escalation on the application layer, the damage actually doesn't really happen when the privilege escalation is such. It happens right after with this particular privilege escalation.

If, of course, the risk or the corresponding SODs, so on and so forth, the whole concept was pretty straight and bulletproof, then, of course, a privilege escalation is a way to get around, but you can't catch that from the nature of the logs. And containing it where it happens, that would be actually a good approach. And that's actually what a defender should do, especially also in SAP. Yeah. So let's look at another question then, which is also one we need to maybe slightly rephrase.

That question is about tools processes that are commonly used today to monitor SAP systems from misconfigurations or suspicious activity and interconnectivity. So what I observe is it's interesting that there are four systems that are so widely used like SAP. There are relatively few SAP security tools add-ons available on the market. Would expect that there are hundreds, but there are maybe a dozen or so.

And yes, there are some internal tools. Some of them are good, some are okay. Some of them clearly are more at the lower end of capabilities. So it seems, I would say there's a gap in using the right tooling to address this. What's your perspective on that? I 100% agree. That's why I always also try to take it down to the core principles on safeguarding a case, how you define, of course, security. And not every tool is suited for every case.

So while, yeah, there are tools with a certain, where they are really strong at confidentiality and integrity, authenticity, availability, for example, granting and securing those principles, I guess those are probably not then the best to ensure, for example, safety as of, if I have a 4.0 industry, like a whole production line, which is actually run by an SAP system connected, then I also need to ensure, how can I ensure here actually the safety aspect? So no one gets hurt entering the suitable piece of software, which solves actually the case.

And there I need to be clear, that is actually one of the biggest fail or the biggest reasons, one of the most common reasons why we see IT security projects fail, especially with SAP, because it's not really clear what needs to be protected. It's just then we need to buy something in order to be compliant, or just the price, we need to be secure, that's it. And that's a wrong approach.

Okay, great. Final question we take, and I have here, maybe I just play it again. And that is again, some question we maybe need to look at a bit different, also from our experience. So maybe the question is, is SAP currently represented in the organization's cybersecurity strategies? What I would say is from a CISO perspective, yes.

So CISOs, look at it, the CISOs I talk to, look at it. And I think this is the point where it really comes currently together. That there's a perspective on it, which is not, from my perspective, not sufficiently reflected in translating and mapping sort of risks into a common language, or having good enough tools necessarily in SAP, but at least where I would dare to say, where I would dare to say that there's at least a perspective on, yes, that is also something we look at in the organization's cybersecurity strategy. I do agree.

And I see a positive trend, to be honest, now a little bit more, I would say, power than 10 years ago, for example. And that makes totally sense, because out of a risk perspective, yeah, when I first started working to work, it was actually probably not that far ago. It was actually seven years ago. We started a poll where we asked around the owner of SAP systems, or the risk owner, the risk owner of SAP security, do you know how long your company can survive when your core SAP system is being shut down? And interestingly enough, around this time, we didn't get an answer.

They always pinpointed, that's something the CISO would know. And then in Germany, Black Peter, yeah, everyone was finger pointing in a circle. And this started to change. We do get now answers and say, okay, well, on average, when we do have this conversation, it's a matter of a few weeks, not even. So a few days, depending on the business purpose, of course, the business, the core business. And therefore, yeah, it's become more and more important. And therefore also more and more visible to the CISO.

Okay, yeah. So almost now with working in IT, SAP R3 was still on the horizon. So it was the age of R2, and the discussions about client server were just about to start. But I think there was a lot of information that hopefully was very valuable to all our attendees, which lets me make thank you. So if there are any other questions, please reach out to us. We'll follow up on these. I think it's a huge topic. It's a very complex and comprehensive topic.

So thank you very much for listening to our webinar, to the insight provided, and hope to have you soon back at one of our other upcoming webinars. Thank you.

Also, thank you from my side, and especially thank you, Martin. Take care. Welcome.