Daniel Frei - Risk-based Access Management @Swiss Re

So I think I would like to introduce Daniel Fry from Swiss re and I was actually quite curious what your presentation will be about because it has a very promising title, which is risk based access governance. I'm really interested to hear what you mean by that and, and, and, and how you implemented it. Okay. Thank you. So ladies and gentlemen, welcome to my talk about risk based access management in Swiss three. And I hope that I, in the next 30 minutes, give you some insights on what is Swiss doing on that topic? My name is Daniel Fry.

I'm the head of the security infrastructure team in Swiss three. And with this role responsible for SNA implies for security infrastructure, but I was also, I am still responsible for the technical implementation of what I'm talking about right now. Let's have a quick look at the agenda. First of all, the in inevitable, I have to introduce you to Swiss three. What is Swiss three doing? Then I will quickly talk about live before EAM.

You will see a lots of references to EAM in speech, and that was the internal name, or is still the internal name for the, the project that deals with risk based access management history. And it stands for enhanced access management. Then of course, that there is typically a case for change. When you do a project, I will show you a short movie on how users see the change.

And then we talk about the technical capabilities that we have implemented the organizational side of the house, which is very, very important, and a couple of facts and figures, outlook, and lessons learned to, to round up my presentation. So this three is celebrating its 150 years of existence this year. It's an incredible long history that Swiss three has, and it is a reinsurance company and in very short reinsurers to ensure the insurers.

So if there is a risk that is too big to be carried alone by insurers, they seek out for help and ask re reinsurers to, to support Swiss three has a, a couple of business lines. You, you see that in the pie chart, we have PNC, which is property and casualty, life and health. Then corporate solutions that is big commercial insurances and admin that deals with closed life books. It is diversified over the globe. You see that the premium distribution is, is quite equal across continent. If I had shown you that graph a few years back, Asia would still be in the single digit.

So Asia is a big growth market. And you also see that income is, is, is spread around those business units. I just mentioned. And that's actually the makes it also so, so successful. There are various business lines where you can easily distribute capital to and invest in the best opportunities. That's the overview from an organizational point of view. And what is important here is that what we are doing is for the whole group, it's not just for one single silo. It is for the whole group of Swiss three.

So what have you done before we started em, in 2001, we started with the so-called corporate directory initiative, which was back then just a simple method directory. And, and you see the various milestones here. I only picked the most prominent ones and there was a constant evolution and addition of new capabilities to our IM landscape.

Maybe I, I pick a couple of those one. Prominent is the full provisioning of 80 and accounts in, in 2006, back then we, we were running with basically one server in the production environment and through the additional loads to the environment we had in 2007, for example, to start separating our environments into an operational domain where we just answer requests and an administrative domain where whole administration is done nowadays in 2013, the, the environment that I'm talking about here consists of about 12 physical or virtualized servers.

We, we have later on a quick look at the architecture, but what I actually wanted to show with that slide is that it is important to take small steps. If you want to do something big in a short time, that is a sure recipe for failure, do it in small steps in well control steps, and you'll be successful.

Now, what, what was the case for change? Why, why did we initiate em, you see it down here.

It's, it's, it's in small print and I, and I understand you can see the slides on the, on the web page later. So I'm not going to read all of that, but the basic takeaway from that slide is that there was no group, right? Philosophy for IEM. Most of the initiatives also listed on the timeline. Two slides earlier were driven by immediate business needs, or it thought, oh, it would be nice to standardize things or audit had a finding that said, you have to get better there and there. So it was not holistically driven. And that was the major drive for this, this program.

Earlier today, I heard it is absolutely key to have people or rather users on board. And whilst most of that is not directly visible to users. It was clear to us that when we are introducing that, we also have to have a good communication strategy. So users know what we are doing, why we are spending a whole lot of money and time with, with that program.

And that is why that As part of the rollout of the em release back in last November, we also produced a short video that showed the user community what em is about Success management at Swiss re This is Katie looking back on her first day in the reinsurance department at Swiss re Katie got a desk, a laptop, and a telephone number, but before Katie could start working, she had to order access rights or specific applications and shared folders. The ordering procedure was not easy, which access rights did she need and where should she start?

Once Katie put in her order for various access rights, Stephanie, her line manager needed to endorse the order request. Other colleagues outside the department had to approve the request as well, manually processing every order added even more time and effort. That's why Swiss re is changing the way employees get their access rights. Katie will soon have a new colleague Jane with the enhanced access management Jane and other new joiners will automatically receive access rights, common to all Swiss re employees. Good for Jane.

She saves time and has less hassle around ordering behind the scenes rules ensure that orders for access rights are not in conflict with compliance access management focuses on two main principles, position based access and the need to protect principle. Instead of ordering access rights, employees get predefined packages containing access rights based on the employees, business domain and job. This minimizes ordering efforts for both employees and line managers. Of course they can still order additional access rights for the package. Furthermore, position based access improves data security.

When employees change jobs within Swiss re access rights are adjusted automatically based on the employee's new role, this minimizes error sources and makes data access safer. The need to protect principle means that Swiss re only protects information, which has been classified as sensitive and confidential. The rest is available to all employees that simplifies Katie's Janes and their colleagues everyday work. The impact of the enhanced access management capabilities can be explained in three S's S as in simpler, S as in safer S as in more streamlined.

And additionally, S as in, soon at your workplace at Swiss rate, enhanced access management at Swiss rate. Thank you.

So, yeah, it's actually not completely correct soon at your workplace that was back in November. So it, it is already at the workplace of our employees. This was by the way, well, well received by our community.

Now, what was the case for change? It was, it was shown in the video. We have been moving from a, from a need to know to a, to a need to protect philosophy, and that then triggers the risk based access management. So we just classify our assets by, by risk classification. And if it's classified as, as highly critical or critical, then yes, it is under the program.

And not, if not, then it's internally available information and is not under that program. You see what our main targets were here. There have been a couple of challenges and most prominently is that there have been a couple of key stakeholders that we first had to convince of that new principle. And of course the, the, that the typical problem we also face is we don't have time for anything.

We, we are in our day to day business and that the business, which is key, and I will show that later in, in a few slides had other priorities than, than to deal with access management. Em is a three year program and started in 2010 with the, with the, with the pre-work with, with building up of the awareness with setting up together project teams. And the first year, 2011 was basically just a conceptual year work on, on, on conceptual stuff.

So how, how are we actually then dealing with that new risk based approach back last year, excuse me, we started with the implementation that is that middle lights, blue arrow implementation of access management systems. That is the part my team was responsible for, and that is still ongoing.

So last November, we rolled out the first release of em, just two weeks ago, we did a roll out of the, of the second release, and we are currently working on the third release with the first release in back in 2011, 12, sorry, we built the basic capabilities, technical capabilities, so that that concept can actually be implemented by the business. What we are doing with upcoming releases is further enhancing those concept and also adding new features that are not currently available. One example are parameters for roles so that you can also add certain attribute to roles, parameters.

And another concept is that roles or assignments of those roles have a certain time period, which might sound simple if you just listen to, to that. So that the, that an assignment is valid from two, but it comes with lots and lots of interesting questions that have to be solved.

What, what is key to our program is that we start an early involvement of all the relevant units that, that had to contribute to, to our program. Now, what are the technical capabilities that we have built? There are basically four. I want to show you a bit more in depth. The first one is what we call business functional roles up, up to the em program. Our roles have been categorized into application driven categories. So application a has a, has a, certain has a couple of roles. Application B has a couple of roles, but it, it was not structured into what we call business functional.

So that a user that has a certain job profile needs application a with that function application B, if that function application F with this function. So these are business function roles that we introduced, the second concept, which we somewhat had introduced, but not consistently is the concept of data windows with roles. You give access to certain functions of a program. You are allowed to add stuff, or to just view stuff with data windows. It is within the function that there are limitations to what you can do. A good example for that is our underwriting community.

People who are doing the contract. Some of them with not so much experience are allowed to sign contracts up to 1 million, for example, and another person with who is, who is a senior, has the permission to sign up contracts to 10 million. So that is an example of a, of a data window. They both are allowed to sign contracts, but with, with various limits, then the two bottom ones are the, from my point of view, the, the most interesting ones, these are the rules, and we have introduced two kind of rules, ordering rule and compliance rules.

Ordering rules is that orders for access rights are processed automatically. So there's no need any longer for a, a user to say, I need access to this and this, but this is automatically assigned to him. And the second one are compliance rules. A user can have two roles, which, which both are perfectly okay, that a user can have that, but they might conflict with each other, an easy example here to understand this. It is not allowed that somebody who is approving a bank payment is also the executor of the bank payment.

This is the interface that we in the first version created for the, for the users you see on the, on the screenshot as an exam, I'm not sure where you want to see it. This is it's a bit small that if you are an internal employee and you are at a certain layer, which means you are in a certain organizational unit and you are out of Zurich, then you get the role claims manager non-life in production. That's a simple ordering rule. And if these three conditions are true, then that the person that, that rule is assigned to gets that. And on the bottom, we have an compliance rule example.

It's, it's that bank, administrator and bank approver. I mentioned before that there's a list of conflicting products. And whether it, it is a no-no, whether it's on the no circumstances allowed to assign such two conflicting products, or whether there can be an exception raised, and that exception can then be approved. As I showed on the timeline, it is, it is important that you have small steps and build upon elements that you well understand and have under control. So what we did is we took the four existing boxes, the, the blue ones here and extended it, them with four orange boxes.

So we had our provisioning system that takes the entitlements and provision stem down to the target systems. We had our directory, the role catalog was there and, and the reporting facility was there. Newly introduced was the store for all the entitlements and the rule engine. The rule engine that that process is ordering and compliance rules on top. You see our it service Porwal, which is based on the service now product. That's why it's called snow.

And on the bottom of the chart, you see the business applications that are provisioned with the output that is generated in the, in the middle layer. And that the other takeaway from that slide is it is also very cost that has a big cost advantage. If you build on, on a, on existing component and here a bit to, to show off, this is the, this is the technical architecture that we have implemented. It is still very high level, but what you see here, it's just a minimal set of interfaces on a high level described.

It is already a multitude of interfaces, and it is important that those are properly orchestrated. So that, that an order, which is not just implemented in, in, in nanoseconds, it takes a while until it is, it is fully executed that all the states in all the involved systems are, are, are consistently over the, over the whole period. And this picture actually also depicts those, those boxes here. And I will show you on the manual ordering case, what is on high level involved on an order?

So if a user is in front of his service Porwal and he makes an order, that order is forwarded to the rule engine for compliance verification, the rule engine then gets the current entitlements. The user that he has, it also gets from snow, any pending orders, because they might also interfere with a, with a compliance decision and then sends back the result. Either it's a compliance violation.

It is not per permitted, that that access product can be assigned to a user, or it is allowed, or it's a no with a possible exception so that somebody can approve the assignment of that conflicting role. Snow then forwards that order to the provisioning system and the provisioning system then puts the permissions ultimately down to the various target systems that might be involved.

And if, if it's a business functional role, for example, that that provisioning might be over a couple of target systems. It's not it's, it's not just one, One can hardly see here, but there is a differentiation between automated provisioning and manual provisioning. Currently we have about 600 target systems, which are provisioned by our platform, but only the minorities fully automated. The majority is there is still an hand interface in between. So the provisioning platform shows to the operator, you need to provision that.

And he provisions that on the target system and then reports that back. But our goal is to more and more automate also all of these manual provisioning systems.

It, it will then be reported back to, to service now that it has been completed. It'll also be reported to the reporting database and ultimately also to the entitlement repository and snow can then on a daily basis compare whether the, the, what was reported back directly and from entitlement repository or in sync, the automated case is a bit easier on a nightly basis.

The, the rule engine goes through all its rules checks, whether that, that then results in new orders or also in on orders. So if that, that somebody loses a certain access, right? This is sent to, to the provisioning system executed, reported back, and then the same with reporting and entitlement repository.

Now, looking at what components are involved, you see on the left hand, up, up left hand side, you see the, the new rule launch, the new rule engine that is based on the axiomatic product. So we newly introduced that ServiceNow was existing, the entitlement repository we built, but we built it upon our standard database system, which is Oracle. And on the bottom, you see that the, the, the provisioning system role catalog that is based on Apache and dear X suite from, from autos.

Now, I talked a lot about technical capabilities, but what I, what I tell you now, the vendors don't like to hear without the organizations organizational side, it's nothing you can build the biggest and best it system to do identity access management. If it, if it's not left in the organization, then that is that then it's investment money for nothing. So with that, with a new approach of the risk based access management, we had to transform the, the whole organization so that they live, that, that new philosophy.

So it, we had to make change organization to the processes and to systems on the organization, organizational side, I'd like to point out two things. One is the group access manager that you see here. That's the new function that we established. He's overseeing the whole identity access management landscape and the, the, the strategy and so on. Plus even more important to my opinion is the business domain, access experts, access experts in the various business domains know best what they have to do in their area. We from it cannot tell them how they should do access in their, in their unit.

So this is one key contribute to the success of the program. Here, you see a bit more about what, what the roles and responsibilities of that business domain access experts are the sake of time, have to hurry a bit a quick look at what and what the costs and that the complexity of the program is we are spending approximately 5 million a year for three years.

So that's, that's 15 million in total. And you see that there are many, many units involved.

It is a, a cross-functional cross unit project, and it is also spread over the globe. So we, you see all the, all, all the countries. So rather the people from what countries have been involved or, or are still involved in that project.

Now, We often refer to our risk based access management as, as, as that puzzle. And here, you see the four major elements of that puzzle on the upper left hand side, you see the information ownership, then you have the risk classification, which we call information at risk. On the left hand, lower side, there is the access right management, how we do the class, actually do the access, right? And on the right hand, lower side, we see all the processes that are involved with, with access management.

It is key that we get support of the, of the important stakeholders and of top management to, to really achieve what, what we're doing here. And that was the case so far. And that's, again, that's one of the key points why it is so successful to start with the classification of information we took intermediate step and took the application and did the classification on the application. So we figured out that six, 600 out of our 1500 are critical applications. And this is based on a couple of matrixes metrics.

One is if it's, if it's relevant from a financial regulations and rules perspective, that is certainly a critical application. If it's data privacy relevant, that is one, or if it poses operational risk, then it's certainly also critical application. Then the information at risk looks at the, at, at the two dimensions, confidential confidentiality, and integrity out of the well known CIA dimensions.

And it, that that task creates a framework to, to consistently access applications and informations for their risk classification. This is something that is now completed, and we, we are now going over the applications and, and do that assessment.

What, what I want to show you here is the, is the continuous rollout into the various business domains. So we do not just big bang approach.

No, we, we start with this business domain and we take the next one, next one, next one. And so on. So this is still ongoing and, and progressing work.

It's, it's not yet completed. What is completed is, as I mentioned, the technical capabilities are there, but now the living in the organization, that's now an ongoing task just quickly look at what we have done two weeks ago. That the, the next release is actually that we are now working on is planned in November of this year.

And again, based on what I said on the timeline, it is important to do small steps and, and, and well control steps. Always make sure that you base it on components that you know, how they are working, that you have well on the control. This gives you the required stability, but nevertheless, it takes a couple of releases until you are there, that where you actually a plan plan to be.

Now, of course, we also learned a lot during that project. And we do that every time.

If, if, if every, every release we do a lessons learned session, the, the single most success factor for that project is, and will be that we do that face approach. Again, if you, if you overload the vacuum, put too much functions too much, whatever into your deliverables, that is a key for failure. What certainly helps is if there is some external pressure, our external pressure was built up by audit findings. There were, and which, which have been repeatedly the same and which have been assigned to top management.

And that then also encourage people to invest enough to, to get rid of these audit findings. Same since we had many countries. So people from many countries involved, it is also key that all that collaboration functions are stable and good enough to work on a collaborative basis, spread around the globe. Nevertheless, it was despite all these tools, it was cumbersome, and it took some time to build up a team and a team spirit across all these countries. But I'm looking back, I'm pretty, pretty satisfied with, with the, with the results that we have reached there.

The second last bullet is a very important one. Even, even if you have functional specifications that say, do this, this, this, and this way, that is most of the times not sufficient. It needs couple of iterations with technical people, with business domain people to really understand all the exceptions and special cases that also need to be considered in implementation. And the earlier you do that, the cheaper is if you only discover such things late in the process, it'll cost you accordingly more. And in the end technical capabilities are just an enabler or a prerequisite.

There is more and far more around that. Again, vendors don't like to hear that they are important, it's the capabilities, but if you don't properly manage it from an organizational point of view, you will not reach good results with that. I'd like to thank you for your attention. And if there are questions, Daniel, thank you for this very, very interesting presentation. I learned a new term. That's need to protect. I like that one. And I hope, and guess there are questions. There's one just, just, just a second. I'll give you the microphone.

I understand that you have a high level of automation when ordering provisioning and de provisioning. What happens if a resource is not available at that time? Will the engine try again later on? Or do we have a, a manual routine to take care of these events? You mean the resource, the, the, the, the final target system where the, where the rights are provision to, yes, It can make quite complex. Yes. Resources that In that case, those, we, we, we call it workflows if such a workflow fails. So throws an error, then somebody is looking into it and tries to fix the, the cause.

But, but it is then tried again and again and again, until it's, it is properly provisioned. Any more questions? I have One, there is one, oh, Sorry, where there, The question I have is in terms of the people aspect of implementing this, how much of resource resources were needed to implement various aspects of the actual rules, the risk identification, and to do the risk identification? What number of people was in the entire team that delivered this?

The whole project team consisted of, I would have to guess, but I would say around 100 persons in total, but that, that starts from business analysts to architects, to engineers, to testers, to, to coders all, all that was, I would say around 100 people in total, I don't have the exact number though. There is one more question With those numbers in place. You've mentioned 50 million Euro and 100 people. How do you measure success? Simple. No more audit findings.

That is, that is certainly one measure. If, if those audit findings that have been raised again and again, again, are gone, then that's certainly an indicator for success.

But even, even now we see a decreasing amount of manual orders and every manual orders involves a person doing that order. It involves a line manager endorsing that order, and also involves somebody approving it, or actually couple of people approving it depending on the, on the classification of that, of that role. So with the, with the reduction of the actual manpower involved, that that's also a measurement for success.

Of course, it's hard to measure it across the company, because if somebody from the business orders, something that does not show up on, on the, any statistics, but we can measure it indirectly by, by seeing how, how many orders have been automated replacing the manual orders. There's one more question. Speaker 10 00:35:19 Do you find that there are less errors with the automatic setup of the, of the access rights and privileges or the manual ones? Good question. The automatic ordering is certainly more dangerous. Why?

So it is not only about provisioning new roles or, or permission to somebody, but it's also about deprovisioning. Now, imagine this, that some or one of that attribute that governs the assignment of a rights to a person is, is wrong for whatever reason.

And it triggers a deep provisioning of, let's say a couple of thousand people, then this is something you you want to avoid, but quality is certainly better if you, if you do it automate that you have, you have business domain experts that look over a certain rule and they decide that this, this, this, and this must be true so that the user gets, gets a certain rule. Whereas if I do it manually, I can browse through the roll catalog and say, oh, that looks promising. I order that.

And that involves then lots of step until maybe the final proof says, no, you are not the person that, that needs that. So there is some additional unnecessary work possibly involved with manual orders where we've automated orders. This is not the case. Does it answer the question? Thank you. Okay. I think we are anyway already a little bit over time. So thanks again for this interesting presentation, I guess, with that Swiss Rees, one of the more mature organizations with regard to access management. Congratulations. Thank you very much. Thank you.