Security and Risk Management Strategies Blog

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.

More Sex is Safer Sex…

Blogger: Pete Lindstrom

… or so says “Armchair Economist” and Economics professor Steven Landsburg in his latest book with the same title. As a security professional I can say unequivocally that I want to be as safe as possible!

In his book, Landsburg talks about the “communal stream” principle – the simple notion that everything we do affects everyone else in some way. In the sex example, the idea is to slow the spread of AIDS by increasing the incidence of sex among partners who are more likely to be uninfected. There are a number of other examples discussing leaf blowers, home security, and pollution that follow the same idea.

The communal stream principle is often expressed in another more common way: we don’t live in a vacuum. It is up to security professionals, then, to determine what the effects are of various actions within our sphere of influence and also for the Internet at large.

And that brings us to the question: Does publishing more information about vulnerabilities make us safer? The impact of vulnerability discovery and disclosure takes on a whole new light when we consider the tradeoffs. Indeed, Landsburg’s subtitle is “The Unconventional Wisdom of Economics” because the results are often surprising to folks that have only superficially considered the consequences. And the Internet’s scalability only serves to accelerate the issue. It’s like giving somebody in Melbourne, Australia strep throat from a loft in New York City.

The communal stream effects are not always apparent with vulnerability discovery and disclosure. If we keep in mind that risk is a function of threats, vulnerabilities, and consequences, then we can also see that if any of these is zero there is no risk. Let’s assume consequences are non-zero and that the vulnerabilities become greater than zero either when they are coded or when an enterprise deploys a vulnerable system. At this point, the only element keeping risk at bay would be a threat value of zero.

Thus, the initial discovery of a new vulnerability does nothing to the vulnerable state of a system. Instead, it starts the risk engine by making threat non-zero. And since we have no infallible pre-cog system of determining motives (consider the similar notion of the insider threat), every new person that learns of the vulnerability increases the threat and corresponding risk. As much as we would like to know about new vulnerabilities, there is no escaping the impact of public disclosure – it is like throwing gasoline on the fire.

Although we know that discovery and disclosure of vulnerabilities increases the (communal stream) risk in the aggregate, it also creates a specific opportunity for protection – the patch. This is where things get interesting… and difficult. For every patch applied the aggregate risk is reduced by a factor the size of the threat – in this case, the number of actors that might exploit the vulnerability.

Since the goal of discovery/disclosure is to reduce risk but the immediate result is to increase it, the real question is, can you reduce your amount of risk to a point at or below where it was before the discovery and disclosure? Some would say “no” because threat was zero by definition. However, it does seem reasonable to assign some level of threat-risk prior to public disclosure simply because one can never be certain that somebody hasn’t already discovered the vulnerability. If an enterprise can patch 100% of systems, bringing the vulnerability state to zero, then it can reduce risk from the level prior to disclosure. In cases where 100% patching (or other protection) is not possible, the product of the remaining number of systems multiplied by the number of threat actors must be less than it was prior to disclosure.

There are two other factors that should weigh in on this equation. The first is the addition of risk associated with new software. For every patch that increases the complexity of software with new lines of code, it is reasonable to expect the vulnerability number to increase as well. So the expectation must be that the decrease in risk associated with plugging the known vulnerability is greater than the amount of new risk introduced by the patch.

Perhaps the most difficult factor to address is the risk foregone due to the increased awareness of secure coding issues. Advocates of discovery and disclosure often cite this as an important point, perhaps even the most important reason for the process. But the comparison they make is always to an absolute, unchanged state, as if there were no other way for developers to learn secure coding practices. Given that the overriding assumption in this entire process is that risk is high to begin with, there would be incidents to follow that would provide the same information at a slower rate. This essentially negates the long-term effect.

The issue of discovery and disclosure is an ongoing one full of debate and rhetoric. It is only when we get to a fuller understanding of risk that we can fully assess the value proposition. In the end, discovery and disclosure is like junk food to the industry – it tastes really good and satisfies short-term desires, but it really isn’t healthy.

“…for only out of the past can you make the future.”

Blogger: Diana Kelley

That’s Jack Burden, Robert Penn Warren’s aptly named narrator of “All the King’s Men.” For most of the novel, Jack tells the story of the complicated politician Willie Stark, from behind an “ignorance is bliss” façade. Over the course of the novel, as Willie’s transformation from honest citizen to corrupt politician (and almost) back again becomes painfully clear, Jack’s forced to examine his own life and reject his detachment; “It was like the ice breaking up after a long winter. And the winter had been long.”

So what’s this got to do with information security and risk management? Well, like Willie and Jack, I think we may need to go back to our past in order to make our future, to melt the hard ice that is freezing out our ability to evaluate alternatives. Specifically, I think it’s time for the industry to take a long, hard look at our assumptions about the need for fully distributed systems, ever more powerful mobile devices, and the trade-offs for risk and security. Remember terminals and centralization of data control? Have you used a Rich Internet Application (RIA) such as Salesforce.com recently? Have you really thought about what we’ve lost by insisting that every user in an enterprise needs to have a redundant copy of sensitive data on their desktop? Laptop? Phone? MP3 Player?

standing in the way of progress, let’s examine where our fantastic power of distribution has gotten us:

• A whole market-space of vendors creating products to protect content: encrypting data on distributed devices, controlling duplication of data to targets such as DVDs and USBs, content control monitoring systems policing the communication information in every packet going in or out of a network or host

• Massive amounts of consumer data going missing from stolen laptops (http://www.usa.gov/veteransinfo.shtml)

• Explosive copies of data leading to fun games such as “who’s got the canonical copy” and “where’d my customer list go?”

• Some large organizations are putting glue in USB ports (really, glue…)

• An alphabet soup of regulations (PIPEDA, HIPAA, GLBA, PCI, to name a few)

There’s more – lots more - but these data points illustrate that the distributed model has created a serious problem for content control. And I genuinely believe that quite a lot of those problems can be mitigated by returning to a more centralized model of data control. If the data is never, ever distributed, except temporarily, to a screen, the content control question changes significantly. Ask yourself, is it easier to filter content from a server to a user screen with access controls on the server or to filter that same content from hundreds or even thousands of replication points? How about application patching? Would it be easier to patch the one copy of the browser on the server that all users access remotely? Or to distribute that same patch to all of the target devices used?

Would a return to a terminal-server (or Web 2.0/RIA-server) model, solve all of our problems? To paraphrase  another  famous fictional character with the initials JB, “it’s pretty to think so” but patently unrealistic. There’s always a way around. There are the possible, but hard to execute, misuse cases such as cell phone camera snapshots of screen information. Really, with the capturing 4 Gigs of customer data using a RAZR, really? Much more concerning is the aggregation of risk issue, if all the data is one place, the single source repository becomes the target attack point. However, even in the distributed model, there is often a central repository that is supposed to hold the canonical copy of the data. And high-availability and data synchronization can provide back-up for central systems.

The trend points for a return to more centralized control of data are already real. Software developers have long used code repositories to maintain version control over code. SharePoint and other data repositories are bringing content together and replacing the recent past of sending multiple copies of documents around via email. Another leading indicator, the explosion of Web 2.0/RIA applications including streaming productivity applications such as Office Live and Google Office and portalized CRM applications such as Salesforce and SAP.

Sure, going terminal-server would change things. The model is dependent on persistent, always on network connectivity. With almost ubiquitous wireless access we’re closer to that reality today than we were a decade ago, but there are still many instances where network access is slow, prohibitively costly, or just plain not available – planes for instance. And all the expensive hardware and operating systems companies have invested in pose a real financial consideration. Dump them for inexpensive terminal, and portable terminal,- only devices? Oh – who manufactures those, yet? Or lock-down expensive, already depreciating hardware to make them dumb terminals? I didn’t say this was going to be easy.

All I’m saying is that - just because we have the ability to do something doesn’t mean it’s the best thing to do. Willie had to learn that his newfound Realpoliltik power to make shady building deals and have extramarital affairs ultimately caused more harm than good both for himself and for his constituents. I think our power to distribute data has hit a tipping point and may be causing us more harm than good and that it’s time to take a look at the past, melt the ice of our assumptions, and rethink centralization.

What do you think?