1 Raindrop

Fatal Separation of Risk Theory and Practice

One of the highlights for me in 2011 was when I got invited to speak at a leading university on the financial crisis. This university is home to some of the most well known and influential economists.

The topic I planned to speak on is the fatal separation between academic theory and real world practice in markets. The notion of risk is certainly at heart of this, Pat Dorsey recently wrote an insightful piece on this point

 

Stipp: You wrote recently a little bit about risk, and you mentioned that a lot of different people have a lot of different perceptions of risk. Can you walk through what different things risk means to different types of investors?

Dorsey: This is a little bit like discussing the existence of God with a theologian. An academic says risk is volatility--the more an asset bounces around in price, the riskier it is.

A mutual fund manager might say it's career risk. If he lags his benchmark for too long, he gets fired.

An individual might frame it as pain. Of course, we feel losses much more than we value gains. So just seeing your portfolio go down is a lot of risk.

And of course Warren Buffett would just define it as permanent capital impairment--the odds that an asset's value will go down and never recover.

Those are pretty different notions.

In my view, these varying definitions of risk are at the heart of what we saw in 2008. In particular, academic models of risk as volatility were hard wired into trading algorithms, and then further juiced by leverage (up 30x-40x leverage!). The risk as volatility assumption by itself would have just led to dumb trades and losses. But with the extra weight and status of the false precision that academic models can provide, this gave large institutions the courage to lever up 40 to 1 and this turned bad trades into catastrophes and meltdowns. Overconfidence in what one could count and ignoring what one couldn't model.

Howard Marks, The Most Important Thing

"According to the academicians who developed capital market theory, risk equals volatility, because volatility indicates the unreliability of an investment. I take great issue with this definition of risk.

It’s my view that — knowingly or unknowingly — academicians settled on volatility as the proxy for risk as a matter of convenience. They needed a number for their calculations that was objective and could be ascertained historically and extrapolated into the future. Volatility fits the bill, and most of the other types of risk do not. The problem with all of this, however, is that I just don’t think volatility is the risk most investors care about.

There are many kinds of risk. . . . But volatility may be the least relevant of them all. Theory says investors demand more return from investments that are more volatile. But for the market to set the prices for investments such that more volatile investments will appear likely to produce higher returns, there have to be people demanding that relationship, and I haven’t met them yet. I’ve never heard anyone at Oaktree — or anywhere else, for that matter — say, “I won’t buy it, because its price might show big fluctuations,” or “I won’t buy it, because it might have a down quarter.” Thus, it’s hard for me to believe volatility is the risk investors factor in when setting prices and prospective returns.

Rather than volatility, I think people decline to make investments primarily because they’re worried about a loss of capital or an unacceptably low return. To me, “I need more upside potential because I’m afraid I could lose money” makes an awful lot more sense than “I need more upside potential because I’m afraid the price may fluctuate.” No, I’m sure “risk” is — first and foremost — the likelihood of losing money."

In obsessing over volatility and price movements, the Efficient Market Theory models missed human behavior in markets (driven by fear and greed), the safety of an asset, the liquidity of an asset in the face of certain events, and an overall conservative approach to investing - try to buy dollars for 50 cents, and not lever up 40 to 1 to buy many $100 bills for 99.95 each. This, of course, goes to the heart of risk management - namely building a wide margin of safety as a hedge against your own ignorance, instead overconfidence in flawed models.

Hedging against your ignorance up front (usually by paying a cheap price) means that you have more time and resources to spend on constructing a margin of safety to protect assets and ensure they are there when you need them. Ill placed confidence in risk models like Value at Risk (VaR) instead of conservative process led people to ignore these two virtues. When events began to unwind the dominoes fell quickly because there were no buffers and no foundation just algorithms gone wild.

I never gave the talk. So what was the highlight you ask? A week after the invitation came, and was ready to talk on the fatal separation of risk theory and practice, I was disinvited for not having a PhD! I often wonder what was discussed in those sessions.

Understanding Cloud Security Standards Part 3

Part three of my three part series on Cloud Security Standards is available on the Intel blog (Part 1, Part 2, Part 3)

Part 1 examines four Identity and Access Anti-Patterns that occur regularly with enterprises moving to Cloud include:

• Low/no access control - we'll see if it works and add security later
• Replicating user accounts - copying enterprise directory in full or extract to Cloud Provider
• Copying credentials - copying or hardcoding credentials to Cloud based services
• “Trusted” proxy - Gateway is a pass through lacking support for security standards and services

Part 2 looks at how SAML, oauth and other standards help enterprises retain control of user management whilst leveraging Cloud services. Part 3 looks at how XACML can be used to close out some of the gnarlier Anti-Patterns through improved integration and granular, dynamic authorization.

Google Renews Push Into China

Two years after saying they were going to be pulling out of China, Google renews its push into China.

Google's share of China's Web-search market fell to 17.2% in the third quarter of 2011 from 36% in the fourth quarter of 2009, largely to the benefit of rival Baidu Inc., according to Analysys International, a Beijing-based research firm.

Even during the APT hysteria of 2010 it wasn't particularly difficult to see that it would go this way. The IMF predicts China will surpass the US as the world's largest economy in 2016 (measured by Purchasing Power Parity). There are benefits to being the largest demand center, as The Economist says "Being the biggest economy in the world does offer advantages. It helps to ensure military superiority and gives a country more say in fixing international rules. "

Costco's Value Chain

Morningstar awarded Costco CEO Jim Sinegal its CEO of the year. Like infosec, retail is a tough business, and Sinegal and Costco succeeded by following a core set of values and by doing things differently.

Several years ago a Costco clothing buyer was able to purchase a large quantity of high-end brand-name jeans at an extremely low price, and the pants showed up in the warehouses for $29.99. The same jeans were selling for $50 at department stores.

It turns out that the buyer was able to negotiate an even better deal on the next order, about $7 less per pair. The idea of keeping the price at $29.99 was briefly floated - potentially bringing in a handsome payoff, considering Costco could sell millions of pairs of jeans. But the notion was quickly and forcefully rejected- and the price dropped to $22.99 a pair, or just a few dollars over cost.

Crazy, right? Yes if you follow traditional retail rationale. But going against convention has been Costco's modus operandi from the start. The person to best explain the approach is Jim Sinegal, Costco co-founder and longtime CEO:

"in traditional retail the thinking is 'Gee, I'm selling this thing for ten bucks, I wonder if I can get eleven for it? The customer's never going to know the difference. We look at it and we say, 'Selling this thing for ten bucks, how do I get it to nine? And then if I get it to nine, how do I get it to eight?'"

This little story illustrates the Costco mindset, which by itself would be an impressive achievement, but Costco values integrity for more than just low prices. At the top SInegal answers his own phone and takes an annual salary of $400k/year. At the employee level, Costco is unique among big retailers in that they pay health benefits, a 50% higher wage, have employee retention rates near 90% (unheard of in the space), and did not lay employees off during the financial crisis. This leads to a great customer experience, and for shareholders the highest valuation of major retailers. You often hear the term "value chain" in business, but Costco actually built one.

Of course, creating a virtuous circle like Costco has isn't easy, otherwise everyone would do it. Its not a stright line path, learning and adapting is required, and this is not an accident either - as Jim Sinegal says "If you aren't spending 90% of your time teaching, you aren't doing your job."

Good News and Bad News

Long before the shenanigans and financial collapse of 2007-8, Dan Geer said that in the financial world risk management works because there is zero ambiguity over who owns which risk and rightly fretted that here in infosec we suffer from nothing but ambiguity over who owns what risk.

First for the Good News, in infosec we're now a lot closer to the financial world in terms of risk management.

Now for the Bad News, the reason we're closer is that many parts of the financial world do not seem to know who owns which risk any better than infosec does.

There are lots of examples of this over the past decade, the one from today was former MF Global CEO, Jon Corzine says he did not know where $1.2 Billion in client funds are.

The majority of these cases in the past decades' financial meltdowns have Derivatives playing a starring role (and yes there are many other drivers but stay with me), the interesting thing here going back to Dan's point on ambiguity in finance is that Derivatives were introduced a Risk Management tool, to smooth out volatility and such, (whether this is even possible is a topic for another day) but in doing so Derivatives introduced an enormous amount of complexity into the system and at the same time inserted ambiguity into where the risk was and how big it was.

We can already buy and sell shares, what derivatives did was give people a way to amplify returns through models, but it also amplifies risk. Derivatives are at the heart of all the rogue trading (Barings, SocGen, UBS, NAB) scandals (watch for my review of How to be A Rogue Trader), and Derivatives are at the heart of 2007-08 collapses.

Derivatives is a case of something with good or at least benign intentions, intended for safety making the system overall much less safe.

**

One of my favorite derivatives quotes from Warren Buffett:

"Long ago, Mark Twain said: “A man who tries to carry a cat home by its tail will learn a lesson that can be learned in no other way.” If Twain were around now, he might try winding up a derivatives business. After a few days, he would opt for cats."

 **

Charlie Munger on derivatives in 2004:

Derivatives
The system is almost insanely irresponsible. and what people think are fixes aren't realy fixes. It's so complicated I can't do it justice here - but you can't believe the trillions of dollars involved. You can't believe the complexity. You can't believe how difficult it is to do the accounting. You can't believe how big the incentives are to have wishful thinking about values and wishful thinking about ability to clear.

People don't think about the consequences of the consequences. People start by trying to hedge against interest rate changes, which is very difficult and complicated. Then, the hedges make the [reported profits] lumpy. So they use the new derivatives to smooth this. Well, now you've morphed into lying. This turns into a Mad Hatter's Tea Party. This happens to vast, sophisticated corporations.

Somebody has to step in and say, "We're not going to do it - it's just too hard."

I think a good litmus test of the mental and moral quality at any large institutions [with significant derivative exposure] would be to ask them, "Do you really understand your derivatives book?" Anyone who says yes is either crazy or lying.

It's easy to see [the dangers] when you talk about [what happened with] the energy derivatives - they went kerflooey. When [the companies] reached for the assets that were on their books, the money wasn't there. When it comes to financial assets, we haven't had any such denouement and the accountings hasn't changed so the denouement is ahead of us.

Derivatives are full of clauses that say if one party's credit gets downgraded then it has to put up collateral. It's like margin - you can go broke [just putting up more margin]. In an attempt to protect themselves, they've introduced instability. Nobody seems to recognize what a disaster of a system they've created. It's a demented system. 

In engineering people have a big margin of safety. But in the financial world, people don't give a damn about safety. They let it balloon and balloon and balloon. It's aided by false accounting. I'm more pessimistic about this than Warren is.

 

Top 5 Security Influencers

Its December and so its the season for lists. Here is my list of Top 5 Security Influencers, this is the list with the people who have the biggest (good and/or bad) influence on your company and user's security:

1. The Person Coding Your App
2. Your DBA
3. Your Testers
4. Your Ops team
5. You

Except for perhaps the last one, what do these all have in common? None of them are in the Security Department!

We shouldn't look at security as a one off, an isolated department of "specialists", but rather leave the ivory tower and look for tools, processes, and training that help the people on this list do their jobs better. Making it faster, better, cheaper and easier to consume and integrate security services into their daily work is the biggest security influencer of all.

Understanding Cloud Security Standards Part 2

Over on the Intel Cloud Access 360 blog I have series on Understanding Cloud Security standards. In part one, I looked at Cloud Security Anti-Patterns. The four Anti-Patterns that occur regularly with enterprises moving to Cloud include:

• Low/no access control - we'll see if it works and add security later
• Replicating user accounts - copying enterprise directory in full or extract to Cloud Provider
• Copying credentials - copying or hardcoding credentials to Cloud based services
• “Trusted” proxy - Gateway is a pass through lacking support for security standards and services

In part 2, I look at how security standards like SAML, Oauth and OpenID help enterprises mitigate the common Anti-Patterns.

You Assert, We Decide

One of the complicating factors in AppSec these days is access control in distributed systems. Dividing up the roles and responsibilities for authN, authZ, attribution and identity management is a daunting task.A typical enterprise is used to putting a ring fence around its assets and managing everything within the fence with RACF/TopSecret, AD, and other technologies. But this is insufficient by themselves for today's integrated applications.

Identity has made a tremendous amount of progress in the last ten years, standards like SAML and OAuth give enterprises a way to make concrete progress on building defensible identity and access control systems for integrated applications like Cloud apps and services. But still we see mucho breaches in 2011. Chris Wysopal found the majority of big breaches to be AppSec related;  while malicious code certainly looks to responsible for some of them others look like access control fails. We don't know the internal architectures of each of the big breach victims, but its not surprising to see authorization on the list. 

The authorization logic is almost always bound up with the code which makes it hard to audit and hard to test. Externalizing authorization to Roles is a nice start but again insufficient for most systems. Attributes change program structure and behavior. This reality must be accounted for somehow, one approach is to externalize via ABAC a la XACML, but many enterprises are just in early stages here. Until then we can and should expect more authorization related breaches due to emergent behavior from unpredictable (and unmanaged authorization systems).

An additional complicating factor for enterprises is the mix of Push/Pull, Bob Blakley addressed the long term view of this so well. Bob also addressed a pragmatic, incremental way to move from Push to Pull via Virtual Directories.  This is an important and as I mentioned I think practical, improvement over how enterprises operate authorization today, however there are code level issues that enterprises will live with unless and until they move to a pure Pull architecture.

Some of the struggles that i have observed are as follows:

• Unclear on granular roles in authorization framework - identity provider responsibility (who asserts) vs service provider (who decides) responsibilities
• Authoritative source of attributes
• How to resolve conflicts between authoritative sources
• Difficulty in seeing where authZ begins and ends in the app code
• Disentangling user identity from app identity

The above is not a complete list but does demonstrate some important challenges for enterprises progressing towards ABAC. (Note- almost all enterprises already use ABAC, in other words the apps' attributes change the structure and behavior of the app, they just don't recognize it as such)

To create clarity on roles in authorization framework - identity provider responsibility vs service provider responsibilities, I recommend mapping out Chain of Responsibility patterns to better understand what authorization decisions are made and where. For each key decision, there should be an approved authoritative source of those attributes.

Where possible, the authorization decisions should be adjudicated at a boundary such as proxy, presentation, business logic and data layers. Not every app is so clean as to support this, but its effective when viable. Resolving authorization conflicts is a tricky proposition in these cases (and made worse by various impersonation/delegation hacks that enterprises back into by cobbling together partial solutions for app/user identity disentanglement), many enterprises simply fail open, which can wind up ending on the big breach list. 

This post isn't a complete overview of what to do, but practically speaking the list above is a subset of issues that enterprises need to solve for while they progress to Dynamic, Pull based authorization architecture. 

Swapping out authorization systems makes swapping out authenticaiton systems look like a tea party. Don't expect this to be super-fast plug and play, its a journey, for many apps its invasive surgery. I mean that literally, like invasive surgery its short term painful and its long term worth doing. The problem must be diagnosed and due to the degree of change required, mapping that to a longer term vision and work through the subset of issues listed above through careful and likely incremental release planning is key to concrete progress.

Interview on Healthcare IT Security

Recently George Hulme interviewed me on Why healthcare IT security is harder than the rest. There are a number of reasons - the overall domain complexity of healthcare versus financial services, the amount of resources that healthcare companies allocate to security and the collission of privacy and security. We also discuss some ideas for healthcare companies and what they can practically do about improving their security posture.

Notes on Cybersecurity Research Agenda from Dan Geer

A new cybersecurity reseach agenda from Dan Geer in three minutes or less - some snippets

1. We would need a lot less research if we put into practice what we already know.  But we don't.  Ergo, why we don't put into practice what we already know is itself a research-grade topic.

Comment: the main blocking factors are usability and integration. As to integration, security is not just "put in the policy and everyone will implement it", its integration engineering to make it faster and cheaper to do the right thing.

Security is not composable. However, in cyberspace, everything critical is a melange.  Gilbert and Lynch's proof of Brewer's theorem finds that in a distributed system it is Consistency, Availability, and Partition Tolerance, choose any two. That tells me there is a research grade result for cybersecurity that will be found to be parallel.

Most security isn't composeable but all the work on federation, SAML, ABAC and other protocols means that we're getting the ability to perofrm more granular and dynamc access control checks across age old point to poitn boundaries. ABAC, PBAC and RADAC are all examples of this and as with the previous point require integration engineering to be effective.

In the 1990s, the commercial world pulled even with the military world in the application of cryptography.  It is now doing the same with traffic analysis (heretofore the strategic redoubt of the intelligence community). While the intelligence community has had the pre-eminent sensor fabric, integrated messaging coupled to geo-location technology is the stuff of hegemony. This is a fact which is not lost on Russia, is not lost on China, and one hopes is not lost on Google.  Is resistance to traffic analysis a research grade question, or is it merely wishful thinking?

PCI helped the private sector make comparatively massive investments in monitoring technology, but PCI solved the easy part - the back end. The domain knowledge required for integration of the audit log messaging and events is lacking in most enterprise deployments, that's a limiting factor to making any of these successful

My research security agenda would have three things on it

1. Integration

2. Integration

3. Integration

After all, why did SAML succeed? Digital signatures and message encryption were not exactly new ideas, nor was capabilities, session management or Single Sign On. It succeeded for several reasons but among them were - pushing the PKI style complexity down the stack where the developers neednt worry about 99% of the ridiculous complexity; in addition it recognized there was - wait for it - a user(!) in the equation and a browser, so there was not some abstract output but rather a set of user operations. 

There were well defined ways to interact with the protocols from a user and a system perspective. This is what we need much more of, to enable the effectiveness of ABAC, PBAC, and RADAC, Bob Blakley's work on moving from Push to Pull protocols in Identity Management is an item that should be high on research agenda because it shows how to get better use of these protocols in real world systems. Federal work on NSTIC, OIX and the like is enormously helpful but as with PCI and logging it helps to solve the first part of the problem. More work is needed to get the front end user and back end containers inherently conversant with the new protocols.