Integrating IT security within the Application Development Lifecycle

Adam Burns. Christophe, thank you very much for agreeing to the interview. Perhaps we can start by discussing your overall IT security risk strategy for UBS. What is your vision there?
Christophe Gabioud. Our vision is to fully integrate the IT security within the application development lifecycle. We have basically two units. One is in charge of the infrastructure, and the other one is dealing mainly with application and data.

In terms of infrastructure, the main challenge is to match all the infrastructure components with the applications. So the application development lifecycle should integrate IT security in all the stages. And we are currently the – this strategy is implemented.

The main focus now with this strategy is to have early – to be involved very early in the development lifecycle, so we usually provide sign-off for the concepts. Yeah, it's a conceptual review. And then once the code is also a more advanced phase, we are also present and have a look on the risks at that level.

IT securities integrated into a global operational risk model, so we also consider physical security, data security obviously, but also vulnerabilities. So we have vulnerability management component, and we have several tools to serve all these elements.

So as IT security risk manager I think there's a real danger of only seeing symptoms perhaps and not causes. How do you work around that?
That's a very good question. So I mentioned the global IT security strategy. We have a risk assessment unit, and they – this unit is specifically geared to deal with early warnings, I would say. So we are proactively analyzing risk in some areas.

For instance, every new development has to be announced and is investigated. UBS runs programs, so it's a set of projects, which are supposed to fit together to deliver a service. And all these programs are investigated by assessors. And it's one way and we are proactive in that area.

One of the added value of the IT security people is to sell that function; I mean, to sell the threats' view, what's coming, and to set up the risk assessment or to reorient the risk assessment according to the threats coming.

So that's one of the added value. It's not only to assess risks because it's quite mechanical. But the added value is really to identify the threats which are against the system. That's for the technical part.

We are also – we are in the moving business, which is dealing with a lot of data, financial data for our clients. We have a high level of confidentiality requirements. So that it means that we also try to anticipate, for instance, with offshoring activities.

We are involved in the assessment. Each time a business wants to go offshore we are coming and assessing the environment in terms of compliance. Is it authorized to have these type of clients' data in an offshore location? And also in terms of staff or technical IT security. So that's a few possibilities we have to be proactive.

We also have some session with regional managements. UBS is structured in four regions mainly, and we have session with regional management where we deal with new issues, coming stuff, problems, and we try to have quite open exchanges at that time. So we are quite proactive and well integrated into the IT organization, so we know the people. We have experienced assessors in IT security people.

So it's a multi-pronged approach, essentially.
There's no simple solution to complex problems, but yeah, for sure we are also sometimes reactive. But we are very oriented in productivity. Our organization is set up to proactive, especially the risk-assessment team.

And what are the greatest risks that you face from an IT security standpoint?
It's a generic threat. It's about the network boundary. Network boundary is getting fuzzy because of subcontractor, offshoring. We have many people moving around, leaving. We have also remote access. We have mobile devices. So it means to really contain and control what's coming in and out is probably the main issue right now.

It's not only one threat. But for instance we have excellent support from excellent companies, which are directly supporting the operation systems production. And that's quite a big challenge to have everything fitting together with some useful controls. So that's the main issue.

And you mentioned there that the periphery is getting fuzzy. This is something discussed at length, of course, by the Jericho Forum, when the rules to the your organization are no longer the rules.
Yeah, exactly. That's a little bit the syndrome. It's really because of business needs. So as I mentioned previously, when we discussed proactively, we're involved in that area. We also have in terms of risk assessment, each time it's needed we are assessing risk. We have also good policies to deal with excellent provider or to outsource data. It's frequent to outsource data, even personal data. So we have a good policy and good checks each time it's required by the business.

But anyway, it's a huge organization, and within that organization there's so many possibilities to have business at the boundary, on one side of the edge. And so we – I mean, the way to deal with that is basically on rule-based access control. So it's not to say, well, this system is inside a boundary, but this system is under control because we know who got access to that system or that data. That's the general – it's not a location-based control, but it's more a rule-based access control.

I think the term risk management is very well described within the organization, but problems occur when the business side wants to make an exception. How do we resolve this? Does risk management – risk managers, I suppose – require a greater voice? Or does there need to be set up a wider authority that can make those judgments?
So the way we do in that is we – the risk management function assess the risk, define the risks and elevates the potential monetary impact in terms of money. That's the first step.

If the business requires an exception because we support the risk, we identify the risk, the bank is at risk, then we have a risk management framework. And we put that risk in the framework and we start discussing with the business. We are a stakeholder of that process, and we have an operation risk controlled function, which owns the process and is the group which is granting the exception.

So into that framework there are discussion between the business, the risk-management people and the risk-control people. And at the end of the day the goal is to really have a good understanding of the risk, to share that understanding with a business, hence the exception is granted by this independent group operation. Risk control is independent. It's not in the business. It's not in the IT. And they have the final word.

Usually the business is responsible for the risk, so once a risk is identified, and if the exception is granted, the business is responsible for that risk and is accountable for that risk. So I mean because of our framework we deal quite easily with exception.

I'm not saying it's simple and quick because there are usually a lot of discussion, depending on the severity of the potential impact. But we deal quite efficiently with exceptions using that framework.

Now, the business need is always for speed and flexibility. The early bird gets the worm, of course. But the operations group is slower and more thorough in its analysis. How do you manage the tension between the two?
We're used to have kind of fire-fighting exercises. So that's true. Sometimes the business is very quick; I mean, it's moving from one day to the other one. And in that specific case we've got people which are very experienced, skillful people, and they know the business. They already know the systems which are involved. So because of that we can react very quickly upon business requests.

It also happens that the business overcomes some decisions. We do some analysis after the business already jump into the next phase, but usually it fits quite well because business people – we have in our organization risk champion in the business. So these guys know very well the business. And its business people – I mean, they are integrated in the organization, and they deal with the risks, the technology risks from a business perspective.

And having the risk-management team and these guys discussing together, talking together, we usually deal with most of the very urgent stuff or problems. And we also define some – we have priorities, so we know that some businesses are more at risk than others because they need us almost daily, so we cannot do all the checks.

So we also have some emergency checks, which can be conducted. And it's being implemented these days, these kind of checks before we just release some applications to, yeah, to follow the business.

And the challenges in information security risk management, or IT risk management, are fairly immature compared to loan or credit risk, for example. How do you move down the maturity curve towards a more quantitative understanding?
Okay. That's a very good question because that's the core of the risk management process analysis. I would say that you're right, the risk model were borrowed to the insurance company model and it's not right model in terms of events. When insurance company has a curve because of, yeah, for instance, the modality curve, it's quite static.

Information security is not static. You cannot tell from one year to the other one what's going to happen. So we are now changing our model at least within the IT security department because at the top level the chief risk officer is still using the standard model and is – yeah, we have to report maturity impact to fit with the other model. Because if you get qualitative analysis for operational risk and financial figures in terms of risk for the other models, you cannot get the big picture for – I mean, the chief risk officer didn't get it, so we have to have that model.

To move to a more natural model we have – well, there is a lot of theory about probabilities in terms of events. So it's not static curves. It's distribution, public distribution, which are quite moving. And to analyze risk and face the risks with this moving target, we are developing now a risk assessment model which is – the goal is to get a lot of data to very broad coverage.

And with that data to have sophisticated, to analyze the data we collected in terms of dimensional analysis. And to be able to, first, to design trends but also to get metadata out of the raw data.

For instance, if we spot an area, the risk access control are weak. We try to analyze that and say, well, what's the cause? And second, if we spot that risk in one area is it a good probability that that specific risk could also exist in another area, in a business or a similar business.

So we try to consolidate these – those data and to have a big picture because when we are assessing risk in a quantitative way, saying, well, in that business, say in Switzerland, you miss some access control objectives, please remediate. Then when it's remediated it's done and closed.

From my point of view that's a bad approach because the business just remediated, and if the risks are faced again we are doing the same job again and again. And that's what we want to evolve into. So we want to consolidate the data, put some plans and address issues globally. And that's the reason why we need a lot of data because just the probability model won't give us enough in terms of, yeah, these event occurred in the past, and now the chance it's occurred again is less.

But it's very difficult to have quantitative analysis. So in order to get out of that problem we gather a lot of data, and that's the system theory is the solution, and it tells us to get a lot of data. So we are developing now a risk-assessment concept that you really have a broad coverage and get a lot of data in all the areas, I mean the risk, the IT risk areas.

And how do you balance the need for autonomy I suppose from each business line, with the need for synergy from a solution perspective across the entire enterprise?
That's a rather difficult issue to solve. We have an architecture team which provides some solution, kind of standards and they can use this solution to build up their applications and also integrate some security components into it. But currently the model is not really mature, and it's still a big issue.

When staff see processes as being time consuming and perhaps not necessarily giving visible added protection, they often become secondary, something that they think about but perhaps don't always do. We get back to Bruce Schneider's classic definition of information security being people processes and technology. How do you mandate in that equation for the people and the processes?
Yeah, that's a big problem because it's not only because of the IT risk management unit. We also have auditors, internal auditors, external auditors, and IT people, for example, are quite often required to answer a question from various people.

So one of the answer is to consolidate. When we get already some data we pick up that data and we don't answer the same question again, or we're trying to do it. Second, I mentioned that the risk-assessment team is adding value by defining threats and consolidating the data.

The risk analysis itself should be really straightforward. The goal is not to – with a risk analysis, the generic risk analysis process, it's not to capture every details. Anyway, that's never possible. But it's to get as much as possible as quick as possible. That's the idea.

So the way we are analyzing risk is very quick. I mean, that gathering process is very quick. We issue a set of questionnaires based on our policies, and we can really check very quickly if something is wrong. So it's more a gap analysis.

The risk management team defines the threats, and because of that definition we can support gaps very quickly. And because of the data we already gather, which are fitting together, we try to avoid bothering people by bugging people all the time with questions. But it's still a problem because, for instance because of compliance.

We have to run the early reviews. And once done that's for compliance. The goal is a little bit different, you know. It's exactly covering all the IT security aspects or the IT risk management aspects. So we need to have some more questions. But we need to have a quick process, a quick assessment process.

Then the added value is to rearrange that data in order to support some pictures and to identify the gaps. But that's the role of the risk assessment team, and it's not consuming time on the business side. That's the idea.

And how do you, especially in times like this when the budgets are getting tighter, how do you balance the expenditure on security risk when there is often no visible reward?
Yeah, the budget is a very good question. There's several answers to that question. First, we can try to leverage cost by finding cheap providers, maybe to have people offshore which are doing the risk analysis but at low cost. That's one possibility.

The other one is to have in the business people who are more dedicated to risks. So it's headcounts on the business side, but the advantage is that it limits the investment. In order to go to a lot of people asking questions we have a person who is in charge of managing risk within the business directly. So that is another approach, which is in place on our side.

And you also have the possibility of what is called the white space. The white space is informer job – most of us have a well-defined job, but within that job there is some flexibility, and there are many people interested in IT security because it's fun. I mean, there's a lot of IT people interested in IT security.

They don't have time to be fully dedicated to it, but they're quite keen to contribute. And to manage these guys, to have this informal process more formal, it is a source of very useful data. So I personally get data inputs from people who are just interested in the IT sector.

There has, I think of necessity, been a huge focus on credit risk recently and particularly its role in the ongoing global credit crisis. But there is a danger that we miss one essential truth, and that is that IT security can bring an ill-prepared organization to its knees with greater speed and fatality. How do you or how can you, in your role, provide confidence to senior management?
This issue is my main concern because I have a technical background in IT security and I know that we could be pretty harmed by people who want to cause damage. It's possible. Well, they can steal something, but they can also shut down businesses.

And it has never happened until now, but I mean, that's the biggest danger, I would say. It's something that can potentially happen. And it's true that the figures here are so huge that the credibility of the risk-management team is questioned. So when I spot a vulnerability and if somebody exploit that, this line of business is down and it's going to be really huge, to generate a huge impact.

That's very difficult to get a buy-in by the business because you have the more urgent problem, and I believe currently the education of the risk officer area is not high enough to understand that. So when we report risks usually the material impact is negligible in regard to credit risks. So that's really a big concern, and some people are aware of that.

But I have to say that it's very difficult to go to senior managers and telling them that you don't know when, you don't know who, but it is possible, and if it's happened we get killed. But it's not because of this it is difficult to tell them, it is also usually highly technical.

You mention that type corruption, if it's done on a large case scale, which is possible. We still have database which are not 100 percent protected. You have flows in an application, etc., so I believe that's the most severe impact, and it's very difficult to be ready for that. I try to have the worst-case scenario, so we are analyzing risk in the worst-case scenario perspective.

We are not that focused on maturity rating. We do it when it's necessary, but we are more focused on worst-case scenario and trying to mitigate that worst-case scenario.

And the risk-assessment process is framed in that way. It's not to define that's a risk and this risk can impact a business. It's to say that's the high of risk we can get out of that IT environment and the recommended set of measures are that set. That's what we do now.

But that's probably the major issue with IT security dealing with senior management. Even if they have an intellectual understanding, the business risks are still so high, and it's very, very difficult to sell the IT risks.

Christophe Gabioud is IT Security Risk Manager for one of the world's leading financial firms: the Swiss giant UBS Investment Bank. Christophe joined the Bank in 2006. He has extensive experience in the Security industry. As a senior IT Security Manager, he is responsible for IT Security matters in Switzerland. Christophe Gabioud is also in charge of the global Operational Risk Assessment Process design and implementation.