Bank’s Security Chief Focuses on Targeting Risk

The constant need to patch vulnerable systems on its vast globalnetworks has been driving London-based Standard Chartered Bank to amore risk-based approach to vulnerability management. Instead ofrushing out to patch every flaw that’s announced as soon as possible,the goal instead is to implement an approach that helps the bankidentify the problems that matter most and to prioritize its responsesbased on asset value at risk. In this interview, John Meakin, StandardChartered’s group head of information security, explains what the bankis doing to help it identify the most urgent threats to its networksand which IT assets get priority for protection.

What’s driving this whole effort?Deploying patches across a global, international network is a bigchallenge. There are lots of potential difficulties, and of course theyare all magnified every time you have a vulnerability for which thereis an exploit being deployed across the Internet. Given that we havealready invested in automated [patch] distribution across the network,given that we think we have a very efficient way of capturing theinitial information about a vulnerability and a patch, we were lookingto see what other scope we had of making this problem less intractable.

How have you gone about doing that?We really have said the only way of solving this problem is to trulytarget where we deploy patches and when. Clearly, some of the serverson our network are more important than other in terms of the impact onour business. Equally, some of those servers are subject to a greaterlikelihood of any vulnerability on them being exploited. By measuringthese two factors across the whole asset inventory on our network, weare able to know which of our high-value boxes are most exposed whennew patches are released.

How big of a challenge has this been?It’s very simple, very logical and very easy, when you put it that way.But actually doing it is a challenge in itself. First of all, itpresupposes that you have a very accurate asset inventory. We’vealready made some investments on our network which have given us thebeginnings of that asset inventory.

Secondly, we have made investments also in tools which scan for theexistence of vulnerabilities across the network. The third piece of thepuzzle, as an add-on to asset inventory, is a measure of just howvaluable each box is, based on the data and the application that itsupports.

The last piece of the picture is the ability to model, in a repeatableway, how easy it is for a vulnerability on a particular box on aparticular place in the network to be exploited. A trivial examplewould be to say a box on your network boundary facing the Web thatcontains a vulnerability is at a higher risk of actually having thevulnerability being exploited than a box buried on the inside of yournetwork.

If you add this piece, all of a sudden what was once an impossible taskbecomes a more possible task. So for us, it’s not about being slickerin getting the [patches] out there, and it is not being slicker intesting them. It’s more about saying we are targeting the limitedeffort we have on the [most important] boxes.

How effective has this whole strategy been in helping you deal with vulnerabilities so far?We haven’t finished this yet. We’ve taken the risk-driven approach overa period of the last two to three years, really starting from SQLSlammer forward. We started focusing our efforts first of all byscanning for where the vulnerabilities are, and certainly we havedeployed our proprietary risk inventory in order to target the work ofpatching.

Going forward, we are adding this final threat-modeling piece fromSkybox [Security], which we believe will give us a further refinementof our patch deployment process. Skybox provides us with the ability tomodel, in a repeatable way, how easy it is for a vulnerability on aparticular box on a particular place in the network to be exploited. Itwill allow us to go from 100 percent patching down to 35 percent if wetarget just the most valuable boxes, and down to about 20 percent if wetarget just the most valuable resources that are also most at risk.

But you still will be patching all the other systems, right?Exactly. We would have a patch cycle where we first deal with valuehigh/exposure high systems, then value medium/exposure high, valuemedium/exposure medium and so on. We will leave the low value/low risksystems until we have a regular software release.The leisurelyapproach, if you can call it that, would be just to bundle up thepatches into a regular software release if you are just dealing withthe residual population of boxes which are of lower value and are notreally exposed to an exploit.

Who decides how valuable a system is, and what is the process for doing that?We have encapsulated our risk model in an automated tool which we builtto our own design. The tool is used by business guys, developmentproject managers and by us, the security experts.

The business guys are the ones who are the experts in the value that’sin the system and in the data. What they do is sit down with this tool,and they are asked a series of structured questions using a sort ofwizard-driven approach about how bad it would be in financial andreputational terms if certain characteristics of the application andthe data were put at risk. What that does, obviously, is to captureinformation about asset value, which is used to produce an overallrating [based on] confidentiality, integrity and availability.

The development project managers sit down with the tool and enterinformation about how the system is built, and that gives us basicinformation on how vulnerable, in broad terms, that application wouldbe.

Within our tool is a body of knowledge that allows us to rank thevarious security controls we could deploy, and it maps them toparticular vulnerabilities in design. In other words, a securitymeasure which is about encryption will protect the value that isassociated with confidentiality, but it won’t do anything foravailability. The requirements are then pushed out into the developmentlife cycle, where they are hopefully fulfilled.

So, what is the final rating based on?We rate the application by giving it a value for each of the keysecurity characteristics: availability, integrity and confidentiality.It is then given an aggregate overall value on a scale of 1 to 5, wherea 5-rated application is of very high value to the bank, while 1 has arelatively low value.

What about legacy applications?We are still building up our coverage of legacy applications. Even thatwe are doing in a sort of risk-prioritized order because you can make avery high-level, notional, gut-feel assessment of the importance of aparticular [legacy] application really just by having a knowledge ofhow the business works.

How easy has it been getting business owners to participate? Not easy.I would still say that we get 50-50 direct participation of businessusers. Sometimes it is a business-aligned IT guy who is engaged in theevaluation process.

The evaluation process itself is sort of self-correcting and is reallyquite sensitive to overvaluation. If I walked into one of our heads ofbusiness line’s office and asked him how valuable a system is, hisnatural reaction is to say “high.” They always say “high,” and thatexperience has been confirmed when using our wizards as well. Whatwe’ve found gets better business involvement is when we go back and sayto them, “OK, you have gone through this valuation process and come outwith a 5 for confidentiality, integrity and availability. You dorealize that means that you’ve got to make the maximum investment insecuring those systems?”

By Jaikumar Vijayan – Computerworld (US online)