1 Raindrop

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.