Security and Risk Management Strategies Blog

Measuring security performance

Blogger: Ramon Krikken

Security metrics is an ongoing hot topic (and pain point) for many of our customers and the industry in general. Of course everyone would very much like to find the one elusive key risk indicator (KRI) that near perfectly predicts the future … but predicting the future as usual turns out to be difficult at best. So we are turning our eyes to security performance measurement (i.e. looking at the past) in an upcoming overview and related talk at our annual Catalyst conference.

There are certainly plenty of security metrics out there, even in the performance area. But something to the likes of “number of incidents” or “percentage of systems with up-to-date patches” is at most something to compare with others – if even that – and it certainly does not make an actionable metric. What we need are goals to track towards and ways to understand how lack of performance leads up to incidents and other bad things.  I of course don’t want to give away one of the punch lines, but let’s just say a large part of it has something to do with establishing correct frames of reference.

And there are of course other documents and presentations related to this topic. Hot off the press is an Executive Advisory Program overview “Communicating Clearly About Risk” by Bob Blakley (subscription only), we have a half-day topic devoted to “Proving the Business Value of IT” which will feature plenty of metrics, Jack Santos touches on the bad side of metrics in the “What Will Your Boss Say? The Reality of Security” presentation, and in one way to circle back to risk management Fred Cohen will present “Risk Management: There are no Black Swans.”

So stay tuned for the upcoming document, and join us for the conference July 27 – 31 in sunny San Diego. You can find the schedule at https://burtongroup.wingateweb.com/us09/scheduler/weekAtGlance.do

An unwelcome outsourcing surprise

Blogger: Ramon Krikken 

We keep hearing and writing about the ailing economy, lay-offs, and other bad news concerning vendors (and partners) we do business with, so we’re generally not all too surprised or worried. The news in late December that banking regulators allowed IndyMac bank to skirt regulations wasn’t necessarily surprising, but somewhat worrisome in terms of being able to accurately assess a company’s health. However, this week’s news about Satyam Computer Services cooking their books and overstating their cash balance by $1 billion marks a new high in “things you didn’t quite see coming.” For some it hits particularly close to home because it’s an IT consultancy.
 
When we talk about risk aggregation – when dependencies cause compounded risk – we often think of hierarchies where we depend on vendor A, vendor A on vendor B, and so on. It’s a great way to simplify the risk calculations, but it ignores the fact that there actually is a complex, intertwined vendor ecosystem. We often assume that our simplified calculations are good enough and the best we can do, but as we hand off ever more critical business operations to others we keep losing visibility, and thus lose accuracy in our assessment. Because we can’t check everything, we rely on third parties – audit firms and the like – to help fill in the details, but in the case of Satyam (audited by PricewaterhouseCoopers) this seems to have been ineffective.
 
To further compensate for we rely our yet another set of third parties to create regulations, audit compliance with those regulations, and to let us know when something is amiss. Different vendors, different industries, different geographies, different regulations, different uncertainties and risk – something that’s apparent from Satyam’s ability to cook the books unnoticed, which for many large IT consultancies would be difficult due to Sarbanes-Oxley. It’s almost like trying to make sense of structured investment vehicles (SIVs,) collateralized debt obligations (CDOs,) derivatives, and socio-political influences in “the global economy” … and see how well that worked out, despite regulation and purportedly careful analysis by financial analysts.

The short of it is that – like the economy and life itself –  we can’t map all dependencies, identify all weaknesses and threats, and take a purely proactive stance. Even when all indicators are green (and assuming you have some faith in these metrics to begin with) it is wise to accept that uncertainty exists and have that good old “plan B” as a backup, “plan C” in case plan B doesn’t work, and maybe even something all the way through “plan Z.”
 
Don’t get me wrong, there is nothing wrong with being proactive, but often the security world – in its infinite wisdom – often shifts focus from one extreme (old-school reactive security) to another (new world preventive security.) On top of that the current metrics we use for measuring “security” are not necessarily conducive to even moderately good (i.e. acceptable) predictions, but I’ll hold that thought for another blog post. The result is that we think we know what the ecosystem looks like, but don’t know how accurate we are, and so risk of instability ensues.
 
It’s precisely the unpredictability of it all – and it doesn’t take a financial or IT analyst to see that things have become more unpredictable – that necessitates some good reactive planning to deal with risks of instability. In the case of vendors, this means ensuring that business continuity and disaster recovery (BC/DR) plans are reviewed, adjusted, and tested more often in times like these. There is of course some preparation required to achieve this: business impact analyses (BIAs,) and careful design and testing of the BC/DR processes – including how to replace one vendor’s services with another’s – to name a few activities.

It is always a good idea to keep these plans up to date anyway, but when vendors are announcing cost-cuts left and right you know you need to be prepared. We should expect more events to the likes of Satyam and the Madoff investment scandal – less noticeable during an economic boom, a downturn is where many of these fraudulent schemes will have to come to light.
 
One of our 2009 themes is taking a fresh look at security programs, how security is organized within the business, and how we assess their efficacy. In light of economics, consumerization, and the cloud, to name a few, vendor management and BC/DR are sure to be as high on the priority list as ever.

More Than Roles: Using Data-Centric Security To Fight Fraud

[blogger: Trent Henry]

In identity management, there’s considerable discussion about understanding organizational roles and how toxic combinations of user access can result in fraudulent activity.

At Burton Group’s Catalyst Conference today, UBS’s Mark Swift described this as a “classic” approach to examining security and said it wasn’t adequate for his organization. Mark said, “What we thought of as roles would actually not help us” in the fight against fraud (no small issue in today’s financial-services environment).

Why not?

Several reasons.

Although UBS initially created functional job descriptions and mappings of user activities, they found that these weren’t sufficiently granular and missed important details because of its top-down approach. Instead, they needed a bottom-up approach that focused on data and business process.

Here’s an example challenge: Switzerland has a multiple-hundred-year-old rule mandating that if a party has entered into a contractual relationship, their identity can’t be revealed. Typically in an enterprise, “account representatives” (as a role) would be granted fairly liberal access to a customer record. But for Swiss clients, even an account representative can’t be allowed to see such information, so a role-based model won’t be granular enough to properly enforce policy. This is what Mark described as “jurisdictional data protection” and requires a new process:

1. Map out data (Ask: what information and attributes do applications care about?)
2. Determine what actions must be performed on this data to carry out business processes
3. Analyze what conflicts in data processing can cause harm (or lead to fraud) [For example read/write access to data that allows both booking a financial trade and settling/reconciling the trade]
4. Create a heat map that provides an at-a-glance assessment of where data, applications, and user access allows for potentially fraudulent activity

This is not a simple task. Mark commented, “Application rights for anything other than trivial systems are complex and are often dynamic depending on application-side rules.” This means that security and risk management teams must have deep understanding (or engage with business leaders who have such understanding) of application processes.

Here’s a challenge that comes to mind for me…

It seems there’s a fundamental economic problem for security teams in financial services. Nick Leeson implied this in his talk as well. In order to prevent fraud, management and security/audit oversight teams must have deep understanding of business processes (and in trading, financial instruments) to determine when bad things can happen. The problem is that when someone has obtained this level of understanding, then they are well positioned to actually serve as a trader rather than risk manager. And there's a strong economic pull to go in that direction, rather than as security personnel.

So data-centric security is powerful and important, and leads to much better understanding of business process. But will that have an adverse impact on retaining knowledgeable risk professionals? Let's hope not, because I think data-centric approaches are the road ahead.

IT Security Meets the Crash of 2008

Blogger: Dan Blum

Much as a galactic black hole sucks matter into its maw, the Crash of 2008 has seized the public’s attention. The media is engrossed with the assessment of losses, causes, blame, and – most importantly – predictions of severity for the recession to come.

Not surprisingly, an interesting survey from a friend in the media turned up in my mailbox this morning. Here is what the survey asks, and this is what I said.

Do you believe the IT security market will continue to grow during the global recession?

I’m no economist, and have little faith anymore in the predictions of those who call themselves economists. With imperfect insight into how severe the global recession to come will be, it’s difficult to say how warm or cold the IT security market will get. Also, Burton Group doesn’t specialize in quantitative research, so we can’t fall back on a lot of impressive looking numbers.

That said, it’s the job of the security analyst to look into the crystal ball – however cloudy it may be – and read the signs. My take is this: If the coming economic winter is moderate the security market will remain relatively flat given the strength of regulatory and business drivers for risk reduction. But if the economic winter is severe (as in a new Depression) all bets are off.

On the other hand, hard times tend to bring on more crime and mischief. It’s likely that new or increased IT security incidents will continue to raise risk drivers for spending.

Which sectors do you believe will continue to invest in IT security during the recession?

If its “only” a recession then stronger sectors with strong risk drivers will maintain spending, weaker sectors with weaker risk drivers will cut back, and others will see mixed results. For example:

Banking and finance may cut back spending due to severe financial losses and M&A activity, however, their tendency to cut back will be mitigated by continuing regulatory pressure on privacy and risk management fronts.

Retail would be affected in any recession and could face pressures to cut back; however, retail’s rate of IT security spending is already low, and PCI/DSS compliance mandates won’t go away.

Government, defence, and health industries will likely maintain spending. Education and insurance may maintain spending, or see mixed results.

What IT security products do you believe will continue to do well during the recession?

Many may not do well. Relative to the others some will do “better,” “worse,” or “average.” Taking the product categories as I found them in the survey:

    Encryption:                        relatively better (strong regulatory mandates)
    Biometrics:                        relatively better (government investments)
    Data leakage:                     average (big problem, but limited solutions)
    Mobile security:                  average
    ID & Access Management:   relatively better
    Gov Risk & Compliance:      relatively worse (poorly defined category/solutions)
    End point security:              relatively worse (cut spending on AV?)
    Managed security services:  relatively better (lower support costs?)
    Physical Security:                relatively worse 
    Email Security:                    average

Can you provide any growth/decline statistics/predictions for the future of the IT security market?

While we don’t trade in statistics, Burton Group has strong research forecasting IT security technology evolution and IT security market dynamics. The following reports provide a great deal of insight into the broad outlines of the future of information security:

• VantagePoint 2008: Security Vital Signs
• Shifting Defenses: Security Futures for Networks, Applications, and Data
• The Long Tail of Risk and the Dynamics of the Security Market

Do you think that the IT security sector is still a strong one to invest in?

Given risk and technology trends there is and will continue to be relatively strong demand for IT security technology. That said, most of the money in the IT security market will not be made by pure play security companies but by much larger IT “conglomerate” vendors.

Our “long tail” report describes a dynamic where security spending is driven by continually shifting threats, attacks, and risks and the market is “always consolidating, never consolidated.” There is a continual crop of startups whose technologies mostly fail, are acquired, or are replicated by platform vendors such as Cisco, CA, Microsoft, EMC, IBM, Oracle, etc.

Only venture capitalists can invest in startups and there are relatively few “pure play” IT security companies listed on stock exchanges. Most of those are small cap rather than mid cap or large cap.

What opportunities do you think the current climate will open up to the IT security industry?

The two R’s – Risk and Recession – are clearly in conflict. Organizations will be trying to reduce the amount of risk they must mitigate, and to accomplish the reduction at a lower cost.

IT buyers may be ready for disruptive innovations that lower cost even if they provide less performance or functionality in some cases. For example:

• Thin clients (not a security product, but conferring security benefits) come to mind.
• Locked down desktop and application whitelisting may help organizations take the axe to expensive anti-virus budgets.
• Outsourced or managed security services will continue to make inroads where they can deliver adequate capability and control at reduced cost

How long do you think it will take before the IT security sector is affected by the economic troubles?

a. Immediately            
b. 6 months                 
c. A year                      
d. 2 years                   

There is clearly already some immediate effect from the financial turmoil. As IT and IT security professionals, however, we shouldn’t obsess over the stock market. We need to stay focused on the businesses we are in and find ways for business to be more efficient, more effective, and (still) adequately protected.

Have CrackBerry, Will Travel

Blogger: Dan Blum

It is no surprise for us to hear loose lips flapping in India about a capability to decrypt Blackberry and other carrier traffic.

After all, we’ve done basic threat analysis for years and it was only months ago that I was brought into a company-wide CISO meeting at a U.S. defense contractor to help them hash out their travel policy for mobile devices. Going into the meeting, I knew their policy restricted taking devices to a list of countries considered dangerous – but there was an exemption for BlackBerries.

Our research uncovered that BlackBerry is pretty secure in most respects. It has transport encryption along with optional password protection, remote kill, disk encryption, and S/MIME encryption. Viruses have not flourished on this functionally limited and closed platform. Few if any third party add on programs are required for additional protection. Nonetheless, I went into the meeting prepared to talk with the CISOs about the risks and security limitations of life on BlackBerry.

Was the BlackBerry exemption reasonable? At the time, BlackBerry transport encryption was not known to have been broken (to be fair, the article listed above still qualifies as rumor, not certainty of breakage). However, I pointed out that it is dangerous to assume well-equipped attackers like military or intelligence organizations can’t crack transport encryption. And even if they haven’t cracked the BlackBerry network and whole disk encryption features, sophisticated adversaries have other attack paths. Check out Neal Stephenson’s excellent book Cryptonomicon for a description of how a talented adversary might “see” your keystrokes and screen images through a motel room wall, for example.

If one of your employees – such as a key scientist, project manager, or executive – is targeted for surveillance and is carrying sensitive data through certain countries, one could argue that he or she had better undergo serious counter-intelligence training.  Learn to spot and shake tails, sneak into dark alleys for that BlackBerry fix. Learn to paper the closet with layers of aluminum foil and send messages in the dark. Defend that BlackBerry with encryption, long passphrases, and kung fu. But unless James Bond is running your company, I doubt this is what your executives have in mind for the next business trip!

Assuming your organization’s lower level employees are like needles in a haystack and won’t be bothered could be an exercise in wishful thinking. It is always possible that nation states are monitoring some or all of the airwaves. Not so long ago the NSA had a massive a covert surveillance program in place. Years before the government was reportedly snarfing up terabytes of emails and crunching them through a program called Carnivore. And of course, selective monitoring of people on watch lists continues on a large scale. This is just the surveillance we know about in the U.S. We suspect there’s more behind the scenes and especially in countries such as China. Even if you train your non-specifically-targeted low level employees to write and speak in search-keyword-free code, the carnivore programs of the world are pretty good at sniffing out those interesting needles – such as descriptions of your business plans, manufacturing processes, and trade secrets.

Sound paranoid? I admit that I don’t know what the probabilities of being targeted or monitored are – just that it can happen. It’s the height of arrogance to believe that a nation state can’t get your information if they’ve targeted it and you’re within their borders. And it’s dangerous to rely on security by obscurity when medium or high consequence information must be protected.

What can be done? If key personnel can't dispense with the BlackBerry (or any other email device) during international travel to those countries where information may be most at risk, they (the users) should limit communications to what they’d feel comfortable uttering over a potentially-monitored telephone call. Controlling incoming communications – messages sent by others – is a harder problem. Until data loss prevention (DLP) products become more contextually sensitive about the travel issues, it may be best not to synchronize the BlackBerry with the overseas user’s home mailbox. Instead, have the user give out a temporary address for the BlackBerry and warn senders to be discreet.

Wakeup Call for Risk Management

Blogger: Dan Blum

With the crisis in financial markets still unfolding, it is important to draw what lessons we can from the experience. Since the roots of the crisis lie in a monumental failure of risk management, it’s important to understand more about what happened, and then draw some parallels to our business risk management and  IT risk management situations.

The risk management failure in the housing market and on Wall Street had multiple interdependent dimensions:

• Mortgage lenders abandoned long standing prudent loan practices. They made too many loans that buyers might not be able to repay. Exotic instruments like ARMs, option ARMs, and interest only loans proliferated. In many cases, all pretense of lending standards were abandoned, so-called “liar loans” approved.
• Capital was grossly over-leveraged. Mortgage lenders and other financial services packaged loans into securities, which they sold to raise capital to support more lending. Real capital reserve requirements to back loans were reduced. Of course, if borrowers could not repay loans, all or parts of the derivative securities would become worthless.
• Risk was aggregated at Fannie Mae, Freddie Mac, and mortgage loan insurance companies. These companies bought or insured some mortgage loans, providing something of a backstop should loans fail. Government sponsored enterprises (GSEs) Fannie and Freddie in turn became over-leveraged and securities that they sold were in turn repackaged in the murky brew of mortgage-backed securities called collateralized debt obligations (CDOs) and other exotic instruments returning generous yields.
• Non-Caveat Emptor. Institutional wealth funds and financial services firms who should have known better bought securities that had been deliberately structured to obfuscate risk. They bought securities they didn’t understand with buried tranches of toxic subprime loans..

It was a great Ponzi scheme – one that kept working as long as housing prices were going up; the recipients of subprime loans could always flip that house to the next buyer. Everyone made money. As Chuck Prince of Citigroup famously put it during a July, 2007 interview: “So long as the music is playing, you’ve got to keep dancing. We’re still dancing.” But one month later, the music stopped. Since then, Citigroup and other financial institutions have taken massive writeoffs with more to come. Wall Street titans like Bear Sterns, Lehman Brothers, Merrill Lynch, and AIG have fallen or been bought out.

What can we learn from this risk management debacle?

As business risk managers and investors, we should ask questions like these:

• Does the executive incentive structure of the company encourage managers to dance around risk? Many Wall Street firms paid senior managers 5 times their salary in bonuses tied to annual growth alone.
• Is the company over-leveraged? Is it borrowing too much money and betting it on ventures with uncertain outcomes?
• Are financial models used for risk management realistic? Earlier, I described the mortgage market of the past few years as a Ponzi scheme, where risk management models must have assumed prices would keep rising. Unlike the dotcom boom whose demise many predicted, very few in the industry foresaw the sharp declines to come in housing prices and sales volumes. Historically, the U.S. housing market has been a steadily rising one, but on the other hand the 2000s saw unprecedented rates of price increases. In reality, what goes up must come down.
• Has your company’s risk council ever performed worst case scenario analysis and built adequate reserves? In the days before economics emerged as a would-be “hard” deterministic science, business leaders may have been more cautious, more aware of and more accepting of uncertainty. Events like the Great Tulip Bubble came once in decades or centuries – not every few years. Note that legendary investor George Soros has proposed a Theory of Reflexivity that, if true, helps explain the recent extremes of boom and bust cycles. This theory holds that market participants model market behaviors based on self-interest, and for a time, their manipulations change the reality of the market – until gravitational forces bring it back to earth. Has the music of ephemeral success played to the backbeat of deterministic-sounding economic models gone to your heads and infected your risk management models?
• Are cost cutting efforts pursued blindly? Outsourcing and other forays into treacherous global waters may be giving away the crown jewels. Smart companies cut costs, but they do it in smart ways. Smart companies think like intelligence agencies as they parcel out work to different partners with varying levels of dependability, and they check on those partners.

Risk management failures can also occur at the more technical level of IT security. As IT risk managers, we might ask questions like these:

• Are the accounting and financial systems your IT department supports under adequate control? As Fred Cohen wrote in one of our documents: “Many companies use computers to manage financial systems, and despite the Sarbanes-Oxley Act (SOX) claims about accounts being properly kept, there are many attacks on financial systems that remain. For example, most of the largest financial systems in the world running on common financial databases do not use double-entry bookkeeping and are thus susceptible to all manner of frauds by insiders.” We find it troubling that a prudent control dating back to the 12th century is going out of style in the name of convenience and cost cutting. Kind of like credit checking became anachronistic during the housing bubble, eh?
• Is the “separation” in your “separation of duty” (SoD) for real? Sure the SOX auditors are looking for SoD, and maybe you have different administrators with different accounts maintaining different systems or functions. But when they say Western civilization may be but one weak password from collapse they’re not lying. Look what happened to Sarah Palin’s email account! Weak and straggly SoD is a problem across all critical IT systems where deperimiterization and server consolidation may be bringing down protective barriers, identity management is weak, and strong process controls (e.g., where two people must sign on, one perform a critical operation such as backbone router reconfiguration, and the second observe) abandoned in the name of expediency.
• Are risks being aggregated to unacceptable levels in centralized control systems? There are many ways that risks aggregate within enterprise IT infrastructures as we pursue automation and cost cutting. Network risks aggregate when centralized domain name system control is implemented. Application risks aggregate when common infrastructure is shared among applications. And enterprises aggregate platform risks when they use low-assurance endpoints, authentication, and directory systems with single sign-on to access large numbers of resources and don’t separate high consequence systems.
• Non-caveat emptor: Has IT security really done the worst case consequence analysis, attack graphs, and vulnerability analysis to know when putting more eggs in a supposedly stronger basket aggregates risks to an unacceptable level? Or are you depending only on vendor claims about some black box appliance equivalent of a risk-obfuscated CDO security? Caveat emptor (buyer beware) again! (The good news is we’ll keep talking about promoting vendor and product rating systems so you don’t have to do all the detailed product analysis yourself, but that’s another post.)

There are many parallels between the monumental risk management failure in the financial markets, and the probable weaknesses in our day to day business risk management and IT risk management. Abandonment of prudent practices for profit; excessive leverage and centralization; ill-constructed risk analysis models; risk obfuscation; and a failure of caveat emptor seem to be common problems. Please take this as a wakeup call to sharpen up the risk management thinking, process, and execution.

It's all GRC to me

Blogger: Trent Henry

Each fall the Security and Risk Management Strategies team gets together for annual planning and brainstorming. These are long days spent in conference rooms, followed by evening vacillation: "should I go exercise, or go to the calorie-laden group dinner?" then email, then repeat the next day.

We always try to create a list of key themes for the research year -- things that are top-of-mind to clients, represent interesting trends for the industry, or are potential market "gotchas." This year we looked at the emerging discussion of "GRC" and scratched out heads. We didn't get it. In fact, we thought the market messaging and product direction(s) were potentially deleterious, so one of our key themes was to debunk the solution space of GRC (that's "Governance, Risk management, and Compliance" in case you were unaware; of course, as further evidence of the meaninglessness of glomming these words together, some vendors use "GRC management," which drops the individual management from risk management. On the other hand, it also implies a such thing as "governance management," which, if not redundant, I don't know what is; but don't get me started down the semantic idiocy path...)

Back to the point: GRC is not a solution, technology, or product category. This sentiment has been echoed the last couple weeks by others in the blogosphere, notably kicked off by Rich Mogul (securosis.com/2008/05/13/grc-is-dead).

Of course, the elements of G, R, C are not dead. Governing, managing risk, and responding to compliance obligations are ongoing and critical organizational tasks. The problem is conflating them into a single term. As Burton Group is inclined to say, GRC is a four-letter word that shouldn't be spoken among polite company. Each function is deserving of its own, complete, and separate word. There's no organization in which compliance activities, risk management, and executive governance are rolled into a single person, group, or tool. No sense creating an acronym that implies it.

This is more than terminological, though. The problem is a vast landscape of vendors touting "GRC" functionality, but whose tools operate at widely varied levels of the solution stack (or, more aptly, at very different levels of organizational reporting). Is a SOX risk register a "GRC" tool? Apparently--particularly if you call it "Enterprise GRC." Is a user provisioning and identity certification solution a "GRC" tool? Yes--it seems--because it has a small stake in validating user management controls. And the list of claims goes on... If everything is "GRC," then nothing is.

What this obscures is the real value that many solutions provide: to map various enterprise requirements (regulations and control standards), test controls for effectiveness, and report gaps or problems that need attending. And it's appropriate that certain tools address the audit community, others the security team, and yet others lower-level technical operations groups. What's inappropriate is to call them all some variation of "GRC."

We've published two reports, a Telebriefing, and we plan to talk at some length about these issues at Catalyst in June (San Diego). We'll be talking realistically about governance functions, the landscape of tools, etc. Our intent is to make clear that many vendor solutions provide value to staff at various levels: just don't go looking for some unifying uber-tool called "GRC."

The Fox and the Henhouse

Blogger: Bob Blakley

Yesterday Societe Generale, the second-biggest bank in France, announced that it had suffered almost 5 billion Euros in losses due to the activities of one of the bank's derivatives traders.

Societe Generale apologized for the losses, and explained a three-day delay in announcing the fraud publicly by saying that bank officials needed time to unwind as many of the fraudulent positions as possible in order to limit the bank¹s losses.

Although Societe Generale did not identify the trader responsible for the fraud in their initial communications, he has subsequently been identified as one Jerome Kerviel.

Societe Generale's press release regarding the incident can be found here:
http://www.telegraph.co.uk/money/graphics/2008/01/24/socgen.pdf.

The details of the fraud are not yet completely clear, and uninformed speculation is not likely to be helpful.  But the first paragraph of the bank¹s press release deserves comment.

Societe Generale begins by saying this: "Societe Generale Group (the "Group") has uncovered a fraud, exceptional in its size and nature: one trader, responsible for plain vanilla futures hedging on European equity market indices, had taken massive fraudulent directional positions in 2007 and 2008 beyond his limited authority."

Three things about this sentence are worrying.  First, the fraud is described as "exceptional in size and nature".   The good ones always are exceptional in size and nature.  Common frauds aren¹t usually hard to prevent after you¹ve seen a lot of them; the reason you pay a risk manager is to prevent the exceptional frauds.

Second, the bank describes Kerviel¹s job as "plain vanilla futures hedging." The worry here is that the bank¹s risk managers think futures hedging risks not worth worrying about because they¹re just "plain vanilla."

The third worrying thing is the last clause: "one trader... had taken massive fraudulent directional positions... beyond his limited authority." Clearly his authority was NOT limited; the risk management and governance mechanisms of the bank apparently failed to prevent Kerviel from exceeding his authority, and they also apparently failed to detect his actions in time to limit the damage.

Societe Generale goes on to say this in the last half of the first paragraph: "Aided by his in-depth knowledge of the control procedures, resulting from his former employment in the middle-office, he managed to conceal these positions through a scheme of elaborate fictitious transactions."

The governance and risk management lessons are the two usual ones:

1. The fox is a dangerous guard for the henhouse.  It may be safe to move traders into the design of risk-management systems; it is probably not a great idea to move the risk management personnel onto the trading desk.

2. The most dangerous assumption in the security business is the assumption that there are good guys. The risk management system MUST be designed to be secure even against attacks by insiders who have developed and operated it.

The only way to design a system to be secure against these insider attacks is to have strong attestation, transaction tracking, dual control, and supervision features - in other words, to ensure that activities are carried out in public and reviewed in a timely way.

Societe Generale appears to acknowledge these lessons later in the press release, when the bank notes that "The individuals in charge of his [Kerviel's - ed.] supervision will leave the Group."  Firing Kerviel's bosses will not fix the problem; only improving the bank¹s governance will prevent future frauds.

"Security Failures": Is the sky REALLY falling?

Blogger: Pete Lindstrom

It is fairly common in the security community to lament that security is failing. In fact, it is so common as to essentially be conventional wisdom. I was on a panel in early August when a question arose that suggested this failure as some sort of fact. When I suggested that it wasn’t clear to me that security actually was failing, it made for one of the more humorous moments of the workshop… at least for the audience who laughed in unison at my apparently ridiculous statement.

The notion that security is failing is an interesting one simply because it is a matter of opinion. There are a handful of ways to measure and then evaluate this hypothesis that are more exact and provide insight into the nature of risk management and differences in operational objectives for security. Here are some of these, taken from the position of defining success (we security folks are much too pessimistic for our own good ;-)):

"Success is the complete absence of failure" – given that anecdotal evidence of compromises is used to suggest failure, it only takes one or a handful of incidents to support a hypothesis revolving around success as the complete absence of failure. This appears to be the most prevalent condition described by security professionals to support their belief that security is failing.

"Success means that benefits are greater than the costs" – at the opposite extreme from absolute success is a minimum requirement for success that allows for a high degree of failure. In this case, an environment can fail to the extent that the costs associated with failure do not exceed the benefits associated with IT to begin with.

These two extremes create ends on spectrum that may be used to evaluate success. On the total success side, security professionals provide a critical view of information systems risk that is unattainable (consider an analog in the physical world where the police force in New York City decided to eradicate murders and that a single murder was unacceptable). The real challenge here is that this type of attitude fosters a level of extreme risk aversion and may create the perception of security professional as Chicken Little. While the sky may be falling to us, it is not necessarily so to the rest of the world.

At this other end of the spectrum is where I believe most IT professionals and savvy businesspeople are. That is, they are willing to tolerate some level of "failure" – that is, a number of incidents whose costs are considered reasonable within the scope of the benefits provided by IT. There are many real world analogs once again – for example, shrinkage in the retail world measures the level of theft of inventory, and credit card fraud may be rampant to some, but the credit card industry is very content to make a lot of money even in the face of this fraud. Of course, it is even easier to sustain losses when they are borne by the merchants, but you also don’t see a lot of merchants abandoning credit cards altogether (some do) because the benefits outweigh the risks.

It seems fairly clear that most organizations (i.e. decisionmakers outside of the security profession) favor this latter extreme. The evidence is simple – the growth of IT budgets overall. It would be irrational to continue spending on IT if it were failing. So, either all decisionmakers are irrational (perhaps plausible ;-)) or security is succeeding at least to a level where it is still useful to use information systems.

The notion that security professionals are at one end of the spectrum and decision-makers are at the other is an important one. It highlights the possibility that for all of our talk about synchronizing with businesses, we really are often quite different. This notion hit home personally and ironically during that workshop panel incident mentioned earlier – while everyone laughed at the notion that perhaps security wasn’t failing, at the same workshop the mantra was always about thinking, acting, and speaking in conformity with the business.

Practically speaking, maintaining status quo should never really be an objective, especially in the face of some level of failure. So what is the option? The third alternative is the service-level agreement:

"Success is meeting a specified service-level agreement (SLA)" – an SLA typically recognizes that absolute goals may not be attainable and so we strive to maximize effectiveness while being practical about the existence of some small tolerable of failure. While this is the most common way to measure other IT operational characteristics, it is an atypical one in security. This is not due to inappropriateness, it is simply because there are no universally-agreed upon measures that could make up an SLA at this time. The most useful candidates are not heavily used at this stage. 

In order to create an SLA, we must come up with objectively measurable items. Presumably, these items should also make sense. The most likely candidate for SLAs with respect to security is a measure around control success. Makes sense, doesn’t it, to have an SLA that cuts to the heart of our protection mechanisms?

There is good news here – the health care community has already created a paradigm for measuring the outcome of tests (in our world, "controls"). That is, every test takes event inputs that are either "good" or "bad" by our definitions (i.e. lead to an unwanted outcome) and our measures of control will either recognize this or not. A good event that is recognized as such is a success, as is a bad event that is recognized as bad. These are true positives and true negatives as determined by the test itself. Control failures are well-defined, too – false positives and false negatives are created from good events identified as bad and vice versa.

We are much better off as a profession considering a more tolerant view of information security. That doesn't mean we shouldn't strive for the best, it simply factors in some level of incident occurrence. While this might seem like we are giving ourselves a break, it really means that we are less likely to promote policies and seek controls that are impractical or worse. But the opposite extreme is no panacea – we certainly should be looking for ways to get better, as it almost always appears obvious what could have been done differently to prevent any specific incident after the fact.

The real challenge for the security profession is to create practical SLAs that are both tolerant in a small way yet challenging nonetheless. There is plenty of room in between the two extremes.

Do iPhones Have a Place in the Enterprise? - Security Edition

Tyson the Skateboarding Bulldog

Blogger: Diana Kelley

Burton Group senior analyst, Richard Monson-Haefel, is hosting a panel discussion on iPhone and the enterprise on August 28 and 29. Burton customers can register for the telebriefing here: iPhones in the Enterprise Telebriefing. Richard's invited iPhone interested analysts to join him. I'll be representing "team security.”

My colleague, Eric Maiwald, posted about risk management related to use of mobile devices in the previous post below. Over in the identity blog, Bob Blakley makes the case for why the iPhone is Ready for Prime Time.

And I've been thinking about the risk management questions related specifically to the iPhone. iPhones may well have a place, but I doubt they'll ever be the mobile device of choice for enterprises. Apple's not marketing the device to corporations. The coolest features of the iPhone, a fairly large screen for watching the latest episode of 'The Office' (nod here to SNL's Fred Armisen and his excellent Steve Jobs iPhone parody) or Tyson the skateboarding bulldog on YouTube. iPhones also feature lots of space for storing songs purchased from iTunes aren't the kind of things that makes CEO's decide to kit out every employee with one.

Some organizations allow employees to purchase and use whatever mobile phone they wish, and more employees are purchasing smartphones with browsers, email, and internet access. The iPhone supports IMAP and POP3 access to mail servers. And the Safari browser on the iPhone connects to web accessible corporate email like Microsoft's Outlook Web Access and IBM's Lotus Web Mail.

In cases where enterprises do sanction a specific mobile device, quite frequently RIM's BlackBerry or a Windows Mobile smartphone are the choice. BlackBerries, unlike iPhones, were built for enterprise use and place security at a premium. They're approved for use by NATO and a number of governments (such as Canada, UK, Australia). And the BlackBerry cryptographic kernel has received FIPS-140-2 certification in the US. There are many third party encryption packages (from vendors such as Credant and Utimaco) that allow users to encrypt data on Windows Mobile devices, which provides a layer of security if the smartphone goes missing. iPhones don’t have encrypted data storage.

Then there's the greenbacks. AT&T (the required provider for iPhone) is selling BlackBerries for $39.99 to $299.99 and Windows Mobile smartphones for $99. The iPhone costs $499 to $599. What enterprise is going to spend $400 more for a less secure phone just so employees can watch the latest episode of "The Office?" Enterprise use of iPhones is going to be done by employees that wanted the cool factor of the iPhone enough to spend a non-trivial amount of their own money on it.

Therefore, the question for corporate risk managers is "should iPhones be banned from the enterprise?" Well, is the iPhone more or less secure than other smartphones? Probably not, though there is the issue of inability to encrypt stored data. Smartphone mobile malware is on the rise and if iPhones gain enough market share, they too will be attack targets. Access to corporate mail from employee owned devices is risky, but many organizations allow it due to the perceived productivity benefits. Why should the rules be different for iPhone users?

Patches and updates are critical for device security. iPhones support remote updating so do BlackBerries and Windows Mobile devices, but other smartphones no so much. So there's one factor in the iPhone's enterprise use favor. BlackBerries and Windows Mobile devices support centralized management and remote lock and wipe - the iPhone does not. There are browser vulnerabilities to consider, but there's no data supporting that Safari is inherently less secure than IE on Windows Mobile.

Should iPhones be banned from the enterprise? That's a question each enterprise will have to answer. But if employee owned smartphones are allowed and centralized management and encryption of stored data is not required, than there's no compelling reason to ban access for iPhone users. So let the iPhones in and then folks can gather around the water cooler on Friday mornings to watch the previous night's episode of "The Office" or Tyson on his skateboard.

What do you think? Want to join the discussion on iPhones in the enterprise? Please post a comment or register for the iPhone telebriefing.