Welcome, everyone, to our talk today with Keri Bowman. She's Director of Product Management at Saviynt and she's responsible for the Application Access Governance products. I’m Martin Kuppinger, and I’m the host of today's talk, I am Principal Analyst and KuppingerCole Analysts and Keri and I will talk about streamlining, governing access to applications in a complex and hybrid environment. So welcome, Keri.
Thank you, Martin. It's good to be here talking with you.
Great. So a lot of people surely know about identity access governance, what is application access governance?
So when we talk about identity, we're talking about the full suite of applications that you have as a company, the full landscape and the entirety of the environment. When we're talking about application access governance, we're usually talking about not just managing a particular application, but doing it at a deeper, fine grained level. So it's one step for risk and compliance adherence that goes a little deeper. And that's typically our key financial applications or those that are in some way regulatory compliance related. So we need to take into account the full identity landscape when we’re talking about identity governance, but application access governance is really finding those key applications that we're required to, from a regulatory standpoint, monitor very closely in a fine grained level. And it's how we manage those applications.
So we are talking about applications like SAP, like Oracle e-business applications, probably also Salesforce and a couple of others. - Exactly. - And at the end, I think the picture I tend to draw is a bit that, Identity and Access Governance is really more about breadth of systems. Yes. While application access governance is about depth.
That is a fantastic way to describe it.
Yeah. And so when you say, I think the part of complex is relatively easy to describe for application access governance because we're talking about complex applications, we're talking about the SAP world and all the other line of business applications that are factually in scope. And I think everyone who is in the IT for a while knows that these environments tend to be rather complex. There's also this hybrid aspect. So, with hybrid, when you talk about hybrid, are you touching more on hybrid in a sense of you can run it on premises or in the public cloud or in a virtual private cloud, or are you touching more on hybrid in the sense of: so in the past a lot of organizations primarily looked at SAP and said, okay if you can secure SAP that's the only relevant system.
But nowadays with all the SaaS services, it means you have still frequently a lot of traditional SAP, or maybe a bit of modernized SAP, but you're getting more and more SaaS applications, aligned by business applications from out of vendors. So what is the perspective you take?
I like that you separate it like that because I think both are applicable, right? Even just take the SAP world, for example, we started with on prem ECC being kind of the key application and most people started to wrap their hands around for risk and compliance. But now we see a lot of our customers using Ariba. They're pulling out their invoicing into Ariba and it's in the cloud, right? And then we're seeing them utilize Salesforce and put some of their order to cash pieces in there. So we're seeing them go from, and even SAP itself now we're seeing the customers make the switch to S4 right now. Some of them keep it on prem, but a significant number of them are moving to HANA enterprise cloud. They're moving to public or private cloud. So even within their own systems, they might still have a legacy system that's on prem within SAP, but then one of their SAP systems moves. So I think it’s both of the things you're talking about, it is that you've got, some are SaaS and some are on prem, but then also you've got some of your own specific SAP applications that you've split and have a hybrid environment for. And depending on the interplay of those systems, we need to know what audit is going to consider relevant and in scope for us to be looking at and how we secure those systems collectively, not just individually as an application, but how they talk to each other as well. Right?
Yeah, because at the end, there's also a thing like cross systems, segregation of duties. - Exactly. - Where a SoD conflict not necessarily is only within a system. And I think that's a reality. We looked at it, within SAP world because supplier management and invoicing, there are SoD conflicts we all know about. But once they are, so to speak, not in which always were two modules within SAP anyway, but it was still considered to be within the SAP world right now. This could be in... one in on premise and one could be in the cloud and coming from a totally different vendor. - Excactly. - The same for Oracle or other large providers.
Exactly. And in my experience, at least here in the States, SOCs has been around for 20 plus years. That was originally the big driver for us saying let's really secure our key financial systems, our SAPs or Oracles. And in the last 4 to 5 years, not only are we seeing the shift towards hybrid environments with the customers bringing in more SaaS applications, moving things to the cloud, but we're also seeing our auditors come and say, okay, it's been two decades. We're very well aware of how to secure your key system. What about everything that feeds into it. Do you know if those users have access to systems on both sides? Like your example. Where can we perform one piece of a conflict in one system, and one piece in conflict of another system? And do we have visibility to that? Are we aware of that risk?
Yeah. And I think another point we observe in a lot of discussions is that not only the governmental regulations are playing a very important role, but we also see increasing pressure to, specifically to suppliers, around supply chain risk. And this is not just, are you safe regarding ransomware but this is also, are your business systems safe, do they operate well, can we trust in these? Because if you are affected in the supply chain, then we as the customer, we are in trouble because our production line then may maybe be stopped because we don't get the goods, etc. So we also see, from what I observe in the market, we see this increase and expansion of elemental regulations and we see also additional pressure on trust getting better in IT.
Absolutely. I mean, and if anything, the pandemic brought that more to light, right? That were impacted not only by what we do internally, but if we have locations that are all around the world, we then have to take that into account and then we layer on top of the suppliers like you're mentioning. And so now everyone has a stake in everyone else's operations running smoothly and not having those compliance issues.
We learned a lot about supply chain risks in the past three years, for a number of reasons, the pandemic, war, ships blocking the Suez Canal. So there were so many things and IT risks, attacks, etc.. So we really learned a lot about how vulnerable our supply chains are, but it's a different topic. But let's go back to this application access governance. So what is different? So we talked about the types of systems to cover, but what is different in requirements when a customer says, okay, I'm shifting from my sort of traditional monolithic world to a sort of hybrid and multi-vendor world. So what do you see as the most important requirements for that change.
For me, coming from a governance background, so I spent 15 years in SAP security and that spans things from being the security admin to implementing governance programs and having my sense of that, something that's near and dear to my heart as standard operating procedures and governance processes. And for me, I find that as we're making that transition to that hybrid environment, to those SaaS applications, it's really understanding what our new governance processes and procedures are, not just for the day to day operations of our end users to ensure right that they are following the proper procedures, but really taking into account all of our governance processes that we have in place today and how they may lift and shift or how they may change when we implement those SaaS applications. So within on premise IP system, we know we are looking for risks X, Y and Z. We've got this type of sensitive access. We have specific things that are done in an emergency access or an elevated access ID, things like that. We've got it very well defined, but when we start to move pieces of that into SaaS applications I think is taking the time to go through and make sure that we're defining how is it impacted in this particular application? Is it handled differently? Do I still have the same concerns or are there new ones based on the feature functionality that's available and being used in our SaaS application?
Yeah. So what you're saying is there’s lesser experience than have been sort of gathered the SAP environments over decades. That also means there are not these rule books out of the box which have been developed for the SAP world over the years. But on the other hand, what you are saying and I think this is a very important point and I like this, you can learn a lot for a new environment from the experience you have gathered in your traditional environment. So because at the end of the day, looking at which are the critical risks and you know, something like SAP_ALL exists more or less everywhere. - Yes. - So you can learn from that and say, okay, this is something we need to look at, which is SAP_ALL, it's still one of the things that come up in every conversation that I have around that. And also processes,
so what are the common SoD violations? And the point is when you say, okay, I have whatever my rule book for SAP, or for whichever other system and this is an SoD conflict like creating new suppliers, approving invoices. Then if you shift the invoice part to something different then it means okay, the conflict still exists. You just need to ensure that right now the right transaction in two systems are covered and not just in the one environment.
And you mentioned at the very beginning we kicked off, we talked, we're talking about complexity, right. And as SAP is known for its complexity because it allows you to do so much, that there are so many options. But that does add to the complexity. So to your point, what adds again to complexity is as we move to these SaaS applications, it's understanding that the security design is different for all of these. So what the security design was within what we've become very familiar with our on prem SAP systems is radically different for a salesforce or a workday or, you know, even Ariba is a different setup, even though it is an SAP product. So we know the risk is there. We know we can do invoicing. And while we knew in SAP the t-code and the authorization objects for invoicing, now we're going to put it in Ariba. And we need someone who understands that security structure so that we're appropriately defining the risk there. And to me, that is the key thing, when we talk about application access governance that makes it so critical, is, we've had decades to define what risks are, but now when we try to stretch them across applications with completely different security structures, it is having a tool that will help us do that effectively and efficiently so that we can make sure that we're properly identifying those risks in that complex environment.
So it also means that with your approach here, so to speak, a bit unifying these perspectives. So in the SAP world, it's very SAP centric and yes, we're talking about t-codes and all that stuff, authorization objects, whatever we have there and to do it cross system it means you need to have sort of a made up perspective on that.
Exactly. I know that I used to compare apples to apples. I have an apple and an orange and I know they're both fruit. So it's needing to be able to have a tool that can talk across both and present that unified view to the end user in a way that's actionable and understandable. Because typically our reviewers of risks are not going to be the security people who understand that complex structure. So we need to be able to do that lift for them of the security structure and then present that risk to them in a way that is understandable for them to then go review and action.
Yeah. And there surely is also sort of an organizational skills change aspect on. So take SAP, or Oracle or whatever from the traditional silo to a more heterogeneous world and, frequently surely it's the same people because they care for, they come from the business, they care for certain parts of the business and their IT systems. But right now having different technology. So when you have 10 years or 15 years experience in SAP and then going to Ariba or SuccessFactors, or Salesforce or whatever security model means, there's a huge change and that is truly one of the challenges we are facing.
Absolutely. You know, the business process owners and the business users, they used to have the monolithic, you know, singular application to deal with for the most part. And you're absolutely right, now they are, when I'm doing this piece of my job, I’m in this application, then I'm moving over here to do a separate piece. So just from the training aspect of it, making sure that they're aware of what responsibilities lie within each application and making sure that their users are trained, aware of that and feel comfortable moving between those. That in and of itself is a significant uplift for the business owners.
Okay. One final point. We have application access governance. We have identity access governance. Should they become integrated? And why?
So, I would say the answer to that is, if it ought possible. We know every business is different, right? Some are much smaller than others. But when you think about it, what drives application access governance? It's the access that users are provisioned within the system. Why are they provisioned that access? It's because of their identity, who they are within the company and their responsibilities.
So I can be siloed and use application access governance just to monitor what someone has put in an application. But if I can increase where I'm at and we think about that capability maturity model, if I can get to where things are expected and repeatable, I'm going to improve my governance, I'm going to improve my efficiency, I'm going to simplify it.
So if we just think of the most basic example, I have an HR system to onboard users, and then I have a major application that they use, by linking the identity between the two of those, I can drive the access that provisioned into my key application because I know this user is in this department with this title. They need this X-Y-Z standard access in my main application.
So even with that simple example, we can see the value of linking identity and application access governance. And when we think in a broad scope, right, it just expands the more applications we are using.
I couldn't agree more with that and maybe just as a final note or comment for my side. Auditors are looking at both ends, identity and application access governance, so integration makes sense. Keri, that was a very interesting talk with you. A lot of insights also to me. Thank you very much for taking the time and thank you for everyone listening to this podcast.
Thank you.
Thank you, Martin. Thank you, everyone, for listening.
