Enterprise Domain Annotation based Segregation of Duties strategies

Okay. So my name is Stephan Bosnia, which, and today I don't really want to talk about companies or products. I will talk about a methodology, but first let me try and set the scene. There we go.

Anyway, so we are talking about compliance. What, what I'm talking about today is basically spends all kinds of industries, financial industries, regulated industries, like pharmaceuticals and also production industries. But for most of the examples will use the financial industry because it's more easier to describe what we're doing here. Generally. Let's put it this way. Nobody wants to do IM deliberately people do it because there is regulatory pressure.

And that's how also the, the whole thing that I'm talking about started about 10 years ago when we were talking to the auditors, but just let's see, what are we talking about? Segregation of duties?

Well, segregation of duties means that you have to separate entitlements for the employees to simply prohibit that a mix of entitlement that they get during their lifespan at a company will enable them to do something they should not do, or that the regulator doesn't want them to be able to do. So there are classical things in the, in the OD approach that have been done before. Yeah.

So there is like the German go Schutze it says separate business from it, separate front office from back office on banksters also middle office, separate maker from checker, like payment capture from payment release, separate the trading business from the loans business, separate sales from purchase. Or when we go to the production industry, you have to separate, for example, the R and D sector from the sales and from the product sectors. Okay. So up to now, basically what have been done in the classical IM products is important.

Entitlements were more or less selected at random and say, entitlement a should not be together with entitlement B. Well that in the long run that gets unmanageable. So this is a typical thing that, that happens with the old approach that simply doesn't work. Let's say you have an organization organization, or one organizational unit. One is allowed to grant the loans. Organizational unit two is allowed to work on securities, right? That works pretty well. But now let's say you're in a little branch office, somewhere out in the field, in, in a country and there's just one or two guys, right?

So they have to be able to do both. Otherwise this branch office simply doesn't work. That means you have a completely undetected, potential security bridge. The other way that you could do is you can say application rules, right? Okay. You have application a, you can capture a payment and release payment, and you say somebody who captures the payment is not allowed to release the payment in application a or one same on application two. But now what would happen if you can capture a payment in application one and release it on two, again, you have an undetected combination of security breaches.

So basically, as I said, we had this with it from the auditor and the auditor said, well, we want you to be able to show that you can do segregation of duties purely on a business process level and integrate that with your IAM solution. So we were sticking our heads together at that time in Frankfurt and in London. And we say, okay, what do we have to do? We have to basically put in an abstraction layer. We have to say, okay, we have to take away the rule set from the applications. We have to take away the rule set from the organizational structure.

And then we, we were looking around what is there that we could use as a starting point. And then we looked at the beyond as the banking industry architecture network. And they were, at that time developing something, they called functional taxonomy and we looked at it and the functional taxonomy is something really clever. It's a treelike structure that gives a common name to everything that happens in the financial industry. But meanwhile gets extended also to all sorts of it. And also other businesses it's organized in layers. Let's have a quick look. So this would be layer one, right?

Sounds pretty familiar. You have like asset and wealth management. You have the finance department, you have governance, you have HR investment banking, you have it legal and so on. So these are, let's say the top layers that you would find in the B version. And also then in enterprise domain, annotation. Now look at layer two. As you can see, it goes a little bit more into detail and on layer three, you can see, and it goes further down at the moment. Bian goes down to level five sometimes to level six, but we realized that this is too complicated for most companies to implement.

So we rolled this out in the end and let's say one very big German international bank and that many of them around at like a, a retail bank at a, what is it, a Dutch life insurance and also at Hilty and the production environment. And it's quite interesting to see how adaptive this structure is. Let's see what, what we have to do when you want to implement it. It's mandatory. You need a company specific ed structure first.

So when, when you want to implement it methodology, you have to see what is this company doing? And pick out the parts. You can use the B taxonomy as a, as a starting point, pick out the parts that you need. Maybe add something like when this company is doing something very special and create your tree. Okay. D special elements you will find in the sort of force layer. As I just describe, it's very strongly recommended to have an HR system that gives you correct data of your internal identities, talk to purchase and contract management, especially for the external users.

It's very helpful to have a CMDB, which gives you an accurate view of what you have in terms of terms of hardware and software, a repository of entitlements, covering anything from roles and profiles down to atomic entitlements of all the applications, which are used throughout the system. And now let's have a look how this thing really looks when you start to implement it. The idea is to create sod rules, which cover all the application landscape that you have and not be specific to some single application.

You can see here, you have like a treating application, a you have a banking application B you have a loan application, some back office applications. You might have entitlements or roles. And this is where it starts with the ed mapping. You can say, okay, this entitlement one of trade app, a you say it's trade trade capture, make another one banking application B role one would be payment, subtype, payment capture, subtype payment, termination loan app. See you say loan, loan, application evaluation, and so on. And you have the description here of what the entitlement is doing.

This is, is key to the whole system because depending on the description, the Analyst will decide what the closest matching ed mapping would be. And now we come to another part, the compensating measure, the compensating measure is pretty important so that you don't run into the problem of false positives. I think there is a separate slide with, yeah, you might say, okay, if you have a readonly entitlement, which is says, like print reports for a segregation of duties, that's not a problem because it can't do any harm.

If you want to view it from the point of GDPR, it may be very well a problem. So this is up to the Analyst to implement it. You have a ized principle, like four I six eyes that could be either enforced by the system directly. So if you have like a core banking system, which is intelligent enough, when you are allowed to like capture a trade, you're not allowed to release it on your own. Although you might have both of the entitlements, you could have detective controls.

That means they run afterwards and just flag where the problems are and you might have direct sign off and direct sign of is the biggest problem, because it may already indicate a potential toxicity. That means I can sign off a transaction and nobody else is looking at it.

If I say, yep, go ahead. It does it. And this is basically how you build the combination measures list. And then you also have two more things you have to look at specific white listing is let's say you have a potentially toxic combinations of entitlements that you are aware of, but just say, well, we just currently have a problem with our business processes. We cannot untangle them directly.

We, we allow this, but we are aware of it. And the CSO science that off, that's also fine. You just put this in a list, right list, and you have the business process, domain membership. That's also pretty interesting, but let's say you have your business process landscape, and you have your data flow landscape map to that. And you can say, okay, from this group of applications, no data will ever reach the other group of applications. That means you will not ever have an sod conflict between these two groups.

That means you just create two or more business process domains, and the system will take care of that. Now let's have a look at the rule set. So the first thing you do is you derive what are the requirements that might either come from the regulator, or that might come from the co or whatever, who, who is doing the business business requirements. So you derive the requirements first in plain English or German or whatever you want, write them down. And you will find that most of them are pretty similar.

When you look at several parties that contribute to that, and then you translate these natural language requirements into the annotation of EDA. Then you can say, okay, trading trade capture is toxic to payment. Payment capture trading trade capture is toxic to it. Security user administration, user creation, and so on. Okay. We have to be quick on that. Okay. That would give you a matrix on the layer. One like this layer two layer three gets a bit difficult to read, but never mind. Okay. So we skip on that on the results.

You can see that if you do it like this, you will get a very clean matrix. You have no more blind spots. And this is interesting. So when you run it for the first time, you will get like a graphical. You can have a graphical representation of and see immediately, where are your biggest OT conflict problems? And in this case, it's like it versus customer management, it versus products, customer management versus asset management. And that's the next big, interesting thing. You can watch it from the platform side of you.

You can say here, for example, you have the biggest problem with the financial system and the purchase, right? What you can also do is when you, when you look at that picture and you map your employees to the org structures, you can do a reverse cluster analysis in like SPSS or whatever. And then you can find exactly which org structures cause the most problems. And then you can be a hundred percent sure that these are the organizational structures that have broken business processes. Okay. We can skip this because we're running pretty late. Okay.

Just a quick overview, conventional a based versus ed. The, you can see that the ed is basically better in every aspect. Just the first one. The initial implementation efforts is of course on ed is higher because you have to go through your whole business landscape, application landscape, and do a mapping of all the entitlements once. But once you have it, you can reorganize as often as you want, and your matrix will completely stay untouched. Feel free to go out to BI, look at the, the business landscapes that they currently decide. It's dot org. Just a quick outlook. Before we end.

I, I, I mentioned GDPR and there's a, it looks different to segregation of duties, but at the end, it's not. And we tried to run ed for GDPR and found out that this is pretty interesting. You can use exactly the same engine. You can use the, exactly the same infrastructure. The only thing that you need to change is your rule set. And sometimes of course, the white listing or the compensating measures, because for GDPR, like read only is not a whitelisted entitlement anymore. Just a quick summary. Ed gives you the chance to fully automate the sod process. It's immune reorganization.

It's completely in independent of your it landscape. It scales to any required number of rules and users. We rolled this out once at this one banker said with hundred 57,000 users at that time. Yeah. You can have both detective and proactive controls and that's maybe that's the most, one of the most important the auditor wants you to show that all your entitlements are covered by so D rules normally not easy to do here in ADA, eights, ed, it's very simple. You just show that all the entitlements have an ed eight mapping, and then automatically all the rules will apply to them.

Thank you very much.