EIC 2012 Session: Delivering Actionable Recommendations to Senior Management based on a Structured Risk Identification and Evaluation Process

Okay. That was quick, probably much quicker than connecting my VGA cable to my Mac or something.

I this, so we have two experts here for bank, for risk management and banks, risk and security management and banks. And I would like to take the opportunity to ask them a lot of questions. The only thing I'd like to do first is to introduce a number of terms and definitions so that you can actually, and you can look at these one, right? Can you see this for having this set, set the scene? So risk management very put very simply is the process consisting of about a number of steps, identifying risks, assessing and quantifying risks.

Thinking about mitigation, implementing the measures for mitigation, measuring the result and reporting back to management. Probably you also need to report more than once at the end, but this is very simple. Simply put, and current session will be about what would is the best practice in industry to have a structured way of identifying risks. Because in many cases I have seen current risk identification is very say chaotic. So you go there, there's a risk manager responsible for ending up with a list of risks and he asks a number of people.

So he asks the responsible manager for a specific service. What are the risks that you have identified for your service? It asks the auditor. Have you seen something interesting that you would like me to follow up upon? And it ask, of course the risk manager hears, do you don't you have a catalog of existing risk I could use and ask the people about for getting the things done.

And most, in most cases that ends up in the best of all scenarios with some brainstorming. This is far from being a structured process. To be honest, this is how industry works, but I think it's time to get beyond this and try to implement a more structured approach. And we have here representatives from the banking industry where I believe do their due to their history and experience with risk. They are much better suit to give us some hints and probably we can learn from them what is better to be done. So two approaches I'd like to show very quickly on risk identification.

One is you can actually try and break down a risk. Now this is very specific to security related threats to analyzing the threat, analyzing the vulnerability and trying to classify the corresponding asset that is under attack. So that be one approach for getting down to a more structured way. In this case, you need of course, complete repository of your assets.

First, you need a security description of your security architecture for actually identifying vulnerabilities and you need corresponding external information typically about the threat situation. So this is something one approach to follow. Another approach would be more managerial one, and look at the different elements that you consider in the say maturity process towards cloud architectures.

Today, as you can see in the upper left, we are typically doing risk identification on systems for in the, in the area of service governance. Like for example, the German BSI et contracts is mandating to do. We may add some risks in terms of information governance or looking at the information specific risk, not so much it, but information risk. That's more IO 27 or one. Maybe if we, if we would compare this to, to the previous example, and then we have the cloud basics where you, you need to get them working also in a cloud environment with additional threats and additional services.

And ultimately also you look at the processes that are run. So that might be a maturity model also to look at after identification of risks. So this very short, some, some, some definition, some words, risk classification and assessment is another discipline, which is very important.

Namely, once you have identified risk, how to attach numbers to them. So classically risk is probability terms, times impact. So it's defined by two major variables, but still the question is how do you get these two numbers? Where do you get these from? So I have put here one example for structured way of doing this. This is from OWAS open web application security project.

Again, very security risk specific where you, where you distinguish between threat agent factors and vulnerability factors for identifying the probability of an attack and the technical and business impact for being able to actually say something about the impact of a specific risk. Now, this being said, I'd like to turn over to discussion with our two experts here, Mr.

Cal, who has thank you for that chair all, all day session so far and Dr. Goodine. And if you have questions regarding topics at any time, please raise your hand, shout out loud so that we can hear you. And I'll come down with the mic so that you can ask the question. Okay. Any question at this point? Okay. So let me then start, I'll keep this like this, maybe. So Mr.

Guttin, let me start with you. What is, what is the best practice of risk identification in the banking industry in general?

Fantastic, Fantastic question. I don't know it I'm Interested as Well. Yeah. I think it's more the question to the smaller bank in Frankfurt here, to be honest, I don't know exactly what I hope. I'm somewhat convinced that big banks use. At least what you have mentioned already is the, its the bases E standards. I have no idea what English names of BS iStandard. They are four main books. I think they're even published in English, but at least in German and with a funny name, 100, 101, 2, 3 and four. And so 104 is a risk assessment guideline guide lining book.

And this one is from my point of view, good starting point for smaller banks. Let me say, I think that's the big, the big players have to have better, more structured.

It, it structured methods. And maybe you can switch to your first two slides because I also This one, What was the first one or that was the first one. Okay. That's the first, the second gen, the third, the third, the next, That was this third Thing. So good. I think this is still more or less the reality as you already suggested that this could be the reality. I think this is small, less the reality, but, and at the end we have always, it's always the same, what we have to protect as the details about the customers and the details about the funds of the customers.

It's always the same, so okay. And the risks they're somehow new, but at the end there are some attackers from the external world, some attackers from the, from the internal world.

And yeah, also some attackers, let me say from the political world, which forced us to do many, many things, which are very expensive, but at the end it's always the same. This are only, only it attacks on your data, on our databases. It's not really new from day to day, but now I have to switch to a real big bank and say some things that truths somewhere in the middle, I think.

Yeah, I think we obviously have quite a history in terms of, of risk identification. And over time the maturity has increased.

In theory, you, as you said, you should always start with the data, right? Information is in the middle of everything now in practice, it's at least not in our area.

It's, it's, it's, it's quite difficult to get an good understanding of, of, of the data. I mean, would a big bank have an overall data model? Would you understand, or your people is this probably stored etcetera, at least Deutche bank very difficult. So we thought about what is the best next approach to which comes as close as possible to this. And we did exactly what you, what you mentioned at the beginning.

We said, okay, we have a quite good understanding of what our applications are, which hold the information. So let's, let's start with those, right? And then obviously we had, we have, we have of course a repository holding all our application data. And then we did, self-assessments using quite a, a basic Excel based approach and, and, and ask as well business business, as well as it, people using structured questionnaire to understand the risk in, in each of these applications while we were moving, of course we improved it in multiple ways.

The first observation we had when we did this approach, it was very cumbersome, a big bank like, like us and probably not very different to many others have thousands of it assets. Now, when you throw all these detailed questions on, on these applications, you can keep the organization busy for months and years. And we were never able to, to complete the whole set of, of these applications with this kind of approach.

So the, the next thing we did, we did, we had to come up with some sort of prioritization. So we changed the approach then and said, okay, let's do a Two-Face approach. So we were very lean, basic assessment, basically done by the business to, to understand the criticality of the application. And then we apply a more detailed approach only to the critical ones and a less detailed one to, to the rest.

So that, that already helped. So you, you are concentrating or you're having an application centric view for managing the risk complexity.

Yeah, that was I'm still in the past. Okay. But that was how we approached it. Yeah. Okay. Still in the past means you do it differently today. We added elements to that approach.

So we, we still do it that way. We've now we've now obviously changed the tool.

So it's, it's better support of, of all subject matter experts we need for that process. But of course, applications does not cover everything. Right.

And, and now when you look at the ISO domains, for example, there are a lot more spaces to cover in a risk assessment process. And, and that can be done in an application centric way anymore. Right?

So, so we, we, we now do it in using the ISO structure. I explained that that this is also a face approach.

We have, we have topics which will be covered on group level, and we have topics which each of the divisions and functions cover as well. And then this will all be consolidated to, to an overall picture.

And, and it's still a little bit, how, how would I say hands on hands on approach? It's it's a little bit a work workshop style. So we have, we use the structure of, of the ISO domains that gives us some sort of structure. We use internal sources coming from audit, coming from incidents, taking place, coming from our known open issues. But we also look at, at sources outside, obviously we analyze incidents happening in other banks. We analyze published incidents outside, so this will all be taken into, into equation.

And then we go through all the ISO domains and see what is relevant for us, prioritize them and, and start to manage that Good Topic. I would like to, to bring another aspect into the, our small discussion. What I mean is that we still, we as banking community and I am a part of it. So I have to take care of what I'm saying.

No, but okay. We, from my part of view, we have still to too much security, public security approach.

What I, what do I mean was this, if you, there are some countries like the, the UK, the us and the Netherlands who, for example, display yearly, there losses, there losses in online banking and their losses in, in card banking. We do not pays it's. It's a policy of the German banking community, not only the commercial, but all the, all the banking communities in that K now DK. So we do not display our losses.

I don't know why, because I know the losses losses are, I will not use peanuts word, but the losses are very small, very small, much smaller than the UK, which is about 500 million pounds for the last year, much smaller than in the Netherlands, which is 90 million euros for 2011 and much smaller than in the us, which is on average about 3 billion per year for it's another risk taking policy in the us, our losses are something like this compared with the others. Okay.

And I think that if we would be a little bit more transparent in simply mentioning the losses, how small they are, our counter measures, what really, what we really do in order to protect our customers in order to protect by protecting the customer's society, then this, we would come a little bit more out of the, how to say of the somehow dangerous, not dangerous somehow obscurity corner as from my point of view, as I, I feel that we are in this corner plus politics. Yeah. Because actually you need to guess the numbers, right?

I mean, yeah. So Journalists, if you have no, if you have no data, you can rely on for probability and impact, all you do is trying to read in the sky.

I mean, we, even, we even didn't lose until now we even didn't lose CD was taxpayers or whatever, like what happened and really big banking countries. Yeah.

You know, the cases. So I think we have many how to say it, successes in, in protecting our datas, our customers, the society, but we don't talk about it in public. So we are successful. We are successful, but we seem to be unsuccessful.

Yes, exactly. We don't talk about It. That's a big pitch. Not only for me, I, I can be here for, for the last 11 years, but why Any questions from the audience?

Oh, wonderful. I keep time once for Anita. Yeah. Yes. I don't really have a question. I just like to see you run. So it's anyway. No.

So, I mean, one remark, I mean, I really understand your, your remark about being more open about the incidents. And I think that is, you know, happening on a EU level as well. And there's a number of EU initiatives where they're speaking about extending the, the obligation to report incidents also to the banking sector. I think it's in a new internet security strategy. For example, it's quite explicitly mentioned right now, the legislation only applies to telecommunication providers and Germany is still implementing it in fact.

But I think it's a good, very good thing to, to start reporting about incidents and to start explaining the public and politicians, you know, how, how big the issue is. Actually, I, I just had one other question.

I mean, we were talking about risk management, not working or not being well structured. And I mean, I can, I understand that you're, you're both saying, well, the, the, the methods we're using are cumbersome.

So I, I, I assume it costs a lot of time, a lot of money. Does it happen often? That's just a question out of curiosity. Does it happen happen often that you, you, you, you, you find a threat, you find an attack.

You're, you're losing a lot of money in some way, and, and you have to revise your, your, your, your list of risks, right? You go, you go back to say, Hey, that's strange. My method wasn't working. Fishing was a very low, but it's actually happening very often. I was just wondering how, if, if this kind of crosscheck happens often, and if you have to revise your risk method, often, Let me answer that. So absolutely we will, we will do that.

So obviously we, we, when we find out that we, we missed out important questions or, and that, that happened at least at the beginning, quite often, that people misunderstood the questions or weren't skilled enough to give the right answers and obviously then came to wrong conclusions. So when this happened and we, we, we got aware of that.

We, we did two things. Obviously we had changed the assessment approach, but also invested in education and training so that people have a better chance to give the right answers. And thirdly, and that's probably the most efficient way to do it. Whatever is possible to automate you should automate. So you can get a lot of valuable information directly from the infrastructure. We actually don't have to ask anybody. And obviously that is the most efficient and reliable way to, to, to get this kind of information.

But of course, lots of this information is not possible to, to get it in an automated way. So we will still have certain reliance on this self-assessment approach. Okay.

Here, I'm an academic. So I have different perspective on things for the first speaker. The first speaker mentioned that they don't have a structured approach for risk assessment. So I was wondering whether this is due to the lack of awareness of such structured approaches or the lack of appreciation of the importance of such approaches. My second question to the second speaker, you mentioned a key point, actually, whenever you said the size of enterprise makes it very expensive around a fully-fledged risk assessment exercise.

And you mentioned that you rank assets before you apply the exercise, which is interesting. It'll be interesting to know how you do this, because as far as I know that the objective risk assessment is to help you rank your risks. If you do this before applying the assessment, are you exposing yourself to non risks?

Yeah, I think the, the, the, at least the last question was about our faced approach of what we call pre-assessment and then, and then full assessment. So I think with the pre-assessment, we try to find out our critical applications. That's quite a lean approach. It should not take longer than half an hour for each and every application. So even if you have hundreds or thousands, that's something we absolutely do. There is no tolerance, every it asset has to undergo this, this assessment and, and, and, and the outcome of this is of course, which are the ones where a deeper look is required.

And then obviously a much more sophisticated, detailed questionnaire will be, will be used to, to further assess these applications in order to really identify issues, etcetera. So on the one hand that that, that approach ensures full coverage. On the other hand, it may, it, it, it makes sure that we really have a detailed look at, at our critical application.

So, and, and I give you some ratios when I look at our overall it asset portfolio outcome of, of the preassessment is that roundabout, a third of it is considered to be critical or requires a deeper look and the others not. And of course we repeat that approach on a regular basis. So our frequency is, so our rule internally is we do this every time, a significant change occurs in an application. And if there is no change, we at least do this every three years for each of the applications. So this is, this is industry, best practice.

I can say I've seen a lot, lot of processes, and this is pretty much complete and very up to the limit, what you can do with the resources you need to spend for that process. At least we survived the number of regulatory inquiries on that basis.

Yeah, Yeah. Me, myself being also in academia since now, a number of years, I can also respond to that question. I've been responsible for such a process, also in a big German organization, international one.

And I, I can tell you that the, the academic approaches that we sometimes see in, in research papers and stuff, there are, there are not adequate for practice users simply because of the effort yet you need to, to spend for this. So there's always a business question behind. So if this is an answer to your first question, maybe, so we need from, from an academic putting my academic hat on, I would say we need more research on making simple, but yet efficient models for risk identification.

So any final remark you would like to make on things you would like to give the people away in terms of risk management, risk identification, evaluation. Yeah, I, I think what that, that probably fits also to, to one of the topics of the conference.

We, we now see, of course that, that this whole space is maturing. We see development in methodology, so it's not necessary that the companies themselves think about it. So we see help from outside organizations, such as IX, such as ISF and, and, and others. But we also see that GRC tools help us in that space. So one example being that we are, we are also part of, of an assessment consortium, I would say called shared assessment. What is meant with that is we share, we share our knowledge of compliance vendors have with regard to information security.

And these questionnaires, for example, are already implemented in some of GRC tools, which then obviously can be used by, by everybody. So that development comes, comes into play here.

And, and, and then that's good. Thank you, Dr. Goin. I am the wishing guy today. I have a small wish we should start. We banks should start to think about common risk assessment, about 80, 85, even 90% common risk. We all have. We all share, let me say, and the rest of 10 or 5% each bank can, can do for itself, but for the 80, 85%, we should try to come somewhere together, Economies of scale in risk identification.

So to say, It's, it's not how to say it's banks. Not only my banks, all banks do not want to behave Lexus.

Yeah, I understand that somehow, but I think we should join forces. So It's a culture cultural thing, obviously, as you said earlier, it's difficult to talk about my own risk. If I'm not have enough self-confidence that I can, can handling them well, right. It's Like losses discussion, which we do not have in Germany. Thank you very much. Give me a big hand.