1 Raindrop

Prawo Jazdy

If you are looking at ways to propagate identity data in a distributed system, consider the mysterious case of Ireland's worst driver - Prawo Jazdy.

He had been wanted from counties Cork to Cavan after racking up scores of speeding tickets and parking fines.

However, each time the serial offender was stopped he managed to evade justice by giving a different address.

But then his cover was blown.

It was discovered that the man every member of the Irish police's rank and file had been looking for - a Mr Prawo Jazdy - wasn't exactly the sort of prized villain whose apprehension leads to an officer winning an award.

In fact he wasn't even human.

"Prawo Jazdy is actually the Polish for driving licence and not the first and surname on the licence," read a letter from June 2007 from an officer working within the Garda's traffic division.
...
"It is quite embarrassing to see that the system has created Prawo Jazdy as a person with over 50 identities."

Claims, even verified claims, need to be evaluated to be any good. They can never be better than your verification process, but they can be worse.

Free as in download it and read it

Good stuff - the Burton Group made Bob Blakley's Identity Relationship paper freely available. I posted my thoughts on it here.

Identity Relationships

First off, I am of the opinion that many of Infosec's ills begin and end with the failure to see relationships and instead pass off binary notions of secure/insecure with silver bullet "solutions". 

Phil Windley's interview with Bob Blakley on identity relationships describes some very important subtle differences in identity. The distinctions Bob describes are very valuable to unlock some ways we can differentiate identity, threat models, protections, and use cases. Hattip to Adam for pointing this out, here are my notes.

* Identity as a standalone artifact is unsatisfactory. Identity creates relationships. Hannaford, TJX, Heartland stored more data than they needed. When it was breached it created a set of business relationships for those companies. There is no free lunch.

* When we are talking about identity, we are talking about people not data or programs but people (note - one trick I have used several times in the past is when a programmer is taking a shortcut on a security design and says "X will be good enough" I then ask if we can test X using his SSN or bank number. This often produces a design change. If that doesn't work ask if you can use their Mom's SSN or bank number, you get the idea)

* Bob describes three types of identity relationships - 1) custodial for high value - like a banks' large customers, 2) contextual - for a specific use 3) transactional relationships - where you need a minimal data set to accomplish a specific often point in time task

As you can see with the above list of relationships when you confuse the storage, usage and security profile of these three types - i.e. aggregate as if you are custodial and then protect like its low value you get a bad business outcome. The job of security and identity architects then is to calibrate cost and effort versus the value created. This an extremely useful way to think about identity information because it leads to distinct actions and outcomes

 

To summarize, identity like security begins with knowing your assets. You can use Bob's categories as a way to think about and value your identities, then your job is to find countermeasures that are commensurate with your value and risk apetite. The classic anti pattern is mismatching weak controls as if you are only using a low value transactional identity but instead you are aggregating tons of high value custodial identity data in a CRM. 

Not Your Father's Data Breach

I am surprised this doesn't happen more often, or become public when it does happen, and I suspect it will:

Corporate custodians of confidential medical data should be closely monitoring events connected to a nightmarish computer security breach in the St. Louis region.

Express Scripts is one of the nation’s largest pharmacy benefits managers. The company, with headquarters in St. Louis County, handles approximately 500 million prescriptions per year for 50 million workers at 1,600 American companies. Early in October, it received an extortion letter, the details of which it released on Nov. 6.

The letter included personal information on about 75 Express Scripts clients — Social Security numbers, dates of birth and, in some cases, information about prescription medications. Whoever sent the letter demanded money from the company — the amount has not been disclosed — and threatened to use the Internet to reveal personal and medical information about millions of people if the demands were not met.

Last week, the criminal activity expanded: Express Scripts said that individual clients had received extortion letters directly.

Express Scripts is cooperating with the FBI in the case. It issued a statement saying it would not pay any extortion demands. The company is offering a $1 million reward for information leading to the arrest and conviction of the extortionist or extortionists.

Beyond the scale of the problem for Express Scripts — and the potential impact on the company is enormous — the issue extends well beyond the mounting concerns about identity theft, a phenomenon with which most people have become at least somewhat familiar.

The greater problem is the unique nature of personal medical records, the importance of moving to computerization of such records to improve health safety and reduce costs and the irreversibility of the damage people can suffer if confidential medical information becomes public. The stakes are so high that a federal law establishes strict standards for maintaining the privacy of medical information and stiff fines for failing to do so.

Medical records of all kinds — paper and, especially, electronic — must be protected with the most sophisticated kinds of security systems available, including backup protections and automatic alerts of security violations. Yet Express Scripts learned of this breach in the “worst way,” as InformationWeek.com security correspondent George Hulme put it in an online report: “via an extortion letter.”

The Express Scripts breach raises many questions for all elements of the health industry: hospitals, clinics and doctors’ practices, benefits management firms, insurance companies, pharmacies, employers and government agencies:
Are they using the most advanced information security technology possible? Do they minimize the amount of data they collect and keep it only as long as necessary? Do they have strict protocols governing access to personal and medical data — and systems to enforce those protocols? If criminals were to hack into their systems, how would the companies know? How soon? And are the systems capable of instantly cutting off illegal access as soon as a breach is discovered?

Confronted with a grave breach of electronic security, Express Scripts has responded by contacting law enforcement, establishing an informational website, offering a substantial reward and hiring a private consulting firm to help clients who have privacy concerns and investigate situations that “appear to be tied to identity theft” and provide “identity restoration services.” There is no question that the company is taking the situation extremely seriously.
Given the ongoing criminal situation, information about how Express Scripts’ data systems were compromised — and whether it could have been avoided — has yet to be disclosed. But the American people have the right to expect that their sensitive personal and medical information is zealously protected and kept secure — not only by Express Scripts but also by every person or company entrusted with it.

The reason I am surprised this doesn't happen more often is that many Fortune 500 companies have oceans and oceans of personal data. Almost the only companies that have even tried to get to a medium level assurance are financial companies, yet many of the other companies have as much or even more data, with lower assurance. All that was lacking in the mix was an incentive and a bit of creativity and risk taking by the bad guys.

I posted this to the security metrics list and Andy Jaquith quoted it in his great book Security Metrics:

"Customers and customer relationships...have tangible measurable value to businesses, and their value is much easier to communicate to those who fund projects. So in an enterprise risk management scenario, their vlaue informs the risk management process...[For example, consider] a farmer deciding which crop to grow. A farmer interested in short term profits may grow the same high yield crop every year, but over time this would burn the fields out. The long term focused farmer would rotate the crops and invest in things that build the value of the farm and soil over time. Investing in security on behalf of your customers is like this. The investment made in securing your customer's data build current and future value for them. Measuring the value of the customer and relationships helps to target where to allocate security resources."

Of course this is the opposite of how most organizations do risk management and security architecture, and now, the fields have turned brown.

I was teaching a training class on App Sec and someone asked how do you get developers to care about security. One technique I use when a developer is saying "well this is not great but its good enough to pass this sensitive data over the wire unencrypted or store it in the clear", I simply ask, "well can we use your Mom's SSN to test this then?" its works more often than you might think.

(Thanks to Chris for pointing me to this story)

Corporate Identity Theft

I remember a talk by the value investor Mason Hawkins (Longleaf Funds) where someone asked him about investing overseas. He answered that he does, but mainly in places where the British flag flew at some point, where there is a rule of law. Here is one example of what he is worried about and why investing in places where your assets have no legal protection does not give the investor a margin of safety.

Hermitage Fund was until recently the largest fund in Russia. From the Business Week story "Hijacking the Hermitage Fund"

Corruption, intimidation, robbery, violent assault, forgery, large-scale fraud. No, not the subject of the latest John Grisham novel, but sensational allegations, made public Apr. 4 by Hermitage Capital Management -- until recently the largest foreign portfolio investor in Russia. In a detailed and damning report, titled Criminal Justice -- Russian-Style, Hermitage alleges the fund's Russian subsidiaries have fallen victim to an elaborate con designed to defraud the fund of hundreds of millions of dollars. 
  
The most sensational part of Hermitage's allegations is that the attempted larceny was carried out with the direct connivance of officials in the Russian police. Hermitage alleges the police seized documents and equipment that were instrumental to the attempted fraud, which involved bogus court cases based on forged documents, the aim of which was to sue Hermitage subsidiaries for hundreds of millions of dollars. "The most shocking thing is not that there are corporate raiders in Russia who attempt to steal your shares," says Jamison Firestone, managing partner of Firestone Duncan, Hermitage's law firm. "The shocking thing is that the police worked hand-in-hand with them, and actually performed the theft of the documents so that the corporate raiders could then do their work."

From the most recent Hermitage Fund letter, here is the current state:

So the two-pronged scam worked in one area and failed in another. The perpetrators weren’t able to steal the assets from us based on the fake court claims, but they were able to steal $230 million from the Russian government by filing amended tax returns on behalf of our stolen companies. What makes this story even more shocking is that we filed six 255-page criminal complaints with the Russian authorities in December last year, one month before the tax fraud took place, and they did nothing to stop it. Two complaints were sent to the Russian General Prosecutor, two to the Russian State Investigative Committee and two to the Internal Affairs Department of the Interior Ministry. There was enough information to prevent the fraud and indict a number of people behind it if the government had acted. 

Instead of doing anything to save the Russian state from this highly sophisticated and organized looting, two of our complaints were thrown out immediately; two were returned to the same Interior Ministry official we were complaining about (essentially, he was being asked to “investigate himself”); and one was thrown out for “lack of any crime committed.” Only one complaint was taken seriously. It was taken up by the Russian State Investigative Committee in early February, but before it could get any traction, the case was lowered to the South region of the Moscow district of the State Investigative Committee (the lowest level of the Committee) and by June, another senior Interior Ministry official whom we had named in our complaint had joined the “investigation” team (again, to “investigate himself”). To this day there has been no serious response by the Russian authorities to this massive fraud against the Russian state. 

As we described in our April letter, the problem of corporate “raiding” is now so endemic in Russia that President Medvedev speaks about it as one of the biggest problems faced by Russian businesses. In this case, raiders have taken this problem to a new and absurd extreme by “raiding” the Russian state itself and so far getting away with it. Together with HSBC, we will shortly be filing new criminal complaints with the Russian General Prosecutor and Russian State Investigative Committee as well as with many law enforcement authorities outside of Russia. It is hard to predict what will happen next in this unfolding and unbelievable saga, but as always we will keep you updated on any further developments as they arise.

Of course we see individual identity theft on a regular basis (actually as Ross Anderson points out its not really identity theft but poor controls on the bank's parts using SSNs as secrets and so on), but you dont see a major corporation stolen every day.

Mission Statement for Federation

Bruce Sterling (11/20/2001):

You know what I want? I don't want a National ID Card. I want a Global Coalition Visa.

Like it or not, we've got a huge global diaspora now. It is a fact of life. Nations with stupid and corrupt politics have seen their clever people brain- drained away, to places where the cops don't shake you down twice a day. And jet-setters go everywhere. And properly so. If you're in a true global society, then you spend a lot of your time among aliens. Quite often you are the alien. You might notice that even Al Qaeda is a genuinely multinational group. They gravitated to wicked, lawless places like Sudan, Chechnya and Afghanistan, where the locals shoot you if you ask for a badge.

But what about all us bright, shiny, world-trading jet setters, huh? There are thirty percent fewer Yankees in Europe this Christmas, and that is bad. Let me pose the problem this way. If I am going into a Japanese restaurant in Japan, I would rather like to be able to haul out some gizmo and flash it at my fellow civilians, and have these kindly people understand with a high degree of likelihood that I am not a mass murderer. On the contrary, I am quite civilized, and I should be brought a beer immediately.

A platinum VISA card and a five-hundred-dollar suit will almost do that, but those are too easy to forge and steal, plus they are not very democratic. The UN should get together on this. We should have a high level summit about digital hardware support for the crippled tourist economy. Fear and ill treatment shut down tourism faster than anything short of open warfare. That is bad for all of us. Killing off tourism harms our civilization and impoverishes our cultures. People in civilized states shouldn't routinely treat one another as criminal suspects. I don't want to get done-over for three hours every time I get off a plane in London. When I go to London, I go with empty suitcases. I don't plan to stay, but I am better news for the London economy than a lot of the people who live there.

They should know all that that before I get off the plane. My arrival is excellent news for Britain, so I should be treated that way. If this is a new kind of war, I don't want to be the evil guy hunkered down in the bunker; I want to fly with the boys from Air Assault. I want one of those handy crypto-style Friend-or-Foe IDs.

These people who normally meet me whenever I am an alien, they don't need to know my nationality, my home address or my shoe size. They just need to know that, despite being alien, I'm sort-of okay.

I want a democratic, citizen-to-citizen device that will bridge those social barriers and language barriers. I think we could invent devices and means of verification that would strengthen the global social fabric that terrorism wants to rip. It wouldn't be easy or simple, but it's not beyond our ingenuity. Our social capital sustains all civilized societies, and it is all about trust. So let's invent new methods of trust.

I added bold to the last sentence because I think this is the mission statement for building out federation systems.

Security Services Deployment in Federated World

Its easy to get hung up on security protocol design, finding the right fit for your architecture and so on. Its really hard to find security mechanisms that do something useful and scale as well. In my opinion, this is the single biggest issue we face in security today - how do find useful things that solve security problems, that can scale in real world systems.

To that end, my favorite paper in a long time was written by Patrick Harding, Leif Johansson, and Nate Klingenstein called "Dynamic Security Assertion Markup Language: Simplifying Single Sign-On." They begin by asking questions companies face when entering into a federation:

How should trust between providers be managed? 

How should information about providers (metadata) be provisioned? 

Which SAML profiles and bindings should be used? 

Which messages and what part of each message should be signed? 

Which identifiers and attributes should be exchanged? 

What are the semantics of those attributes and identifiers?

Organizations understand the benefits of SSO and federation, but don't always answer the above questions in a way that sets them to scale. Harding, et al.'s work describes a way to partition the architecture into separate layers - a metadata trust fabric,a metadata publishing fabric, and a metadata validation and signing fabric - enabling dynamic federation. If you design stuff for a large scale distributed systems, this is a really big deal. No wonder these guys win all the good awards. 

I have often used Federation as an example of security as a business enabler - improving the brakes, ABS, and airbags so we can drive fast and safe. Federation creates value for the business through more deeply linking it with its customers, partners, and business users; it solves some security architecture problems through encrypted and signed tokens; and it gives the user SSO/SLO. You don't always get a win like this in security architecture, but when you find one its good to ride it for all its worth.

Openly IDentify your attributes with Open ID

As developers are inexorably drawn down the rabbit hole that is identity, they continually conflate authentication, authorization, and attributes into one big "identity" jumble. Lately, there has been a lot about OpenID, which as com.burtongroup.analyst.identerati.neuenschwander.mike (known unambigously around the identity water cooler as "Mike Neuenschwander") points out that OpenID is about attributes:

But don’t get me wrong: OpenID isn’t the problem here. OpenID simply calls into sharp focus something I’ve believed for years. It’s a kind of axiom, so I’d like to give it a name. I’ll call it, “identifiers.axiom.neunmike’s.axiomproxy.info”—that way you can easily refer to it unambiguously from anywhere. Here it is:

    There are no identifiers, only attributes

Names are slippery. Most people have many more than one legal name, none of which are unique. They also have several dozen nicknames. There’s no practical way to get any of these every-day-use names onto a global namespace. And what’s a name after all but a synthetic attribute—a foreign key that we hope the receiving party stores somewhere so we can remember them later? Names are invaluable communication aids, but they have little to do with recognition, which is what’s at issue in most identity management contexts. Biologically, creatures don’t recognize others based on names but rather the confluence of attributes appearing within a certain context.

Lao Tzu (who goes by several dozen names) had a pretty good post on this idea over 2000 years ago. In a section called “Ineffability,” he writes:

The Way that can be told of is not an Unvarying Way;
    The names that can be named are not unvarying names.
    It was from the Nameless that Heaven and Earth sprang;
    The named is but the mother that rears the ten thousand creatures, each after its kind. (chap. 1,  tr. Waley)

I understand why from a programmer’s perspective, it would be so much more convenient if everybody could simply have one globally unique, unambiguous, resolvable name. But such a quaint design constitutes a wanton disregard for reality.

The tech industry is adolescently ID-fixated. But I’ve had it to here with IDs! Would somebody please start seeing my avatars as something more than identification objects? So here’s to being an OpenAttribute power user!

Leave it to com.burtongroup.analyst.identerati.neuenschwander.mike to provide clarity on a much misunderstood issue.

org.tbray.ongoing.proprietor.bray.tim (aka com.sun.softwaredivision.canada.ubergeeks.bray.tim) kicked the tires on OpenID and came to a similar conclusion:

What Could I Use It For Today? · Here’s what I think I’d be willing to do: in the commenting system here at ongoing, I’d be inclined, if I had manually approved a comment with someone who’d authenticated via OpenID, to subsequently accept further comments from that OpenID, unmoderated. ¶

I can’t think of anything else.

The real work for developers is not about assigning an uber-GUID to people, it is about unmarshaling attribute values into a PEP and putting them into a context to make them meaningful. As Butler Lampson says, "all trust is local." Again, I mention Bob Blakley's work on Security Design Patterns, that describes several ways to do this in a distributed system.

Hunter S. Thompson said "buy the ticket, take the ride." But don't conflate yourself the ticket and the ride.

CardSpace - not just for Windows any more

Turns out that open source Apache apps can also now leverage stronger portable identity through the work of Ping Identity. Ashish Jain announced the Apache Authentication Module for CardSpace. Kim Cameron commented on another mind-altering announcement from Ping Identity, enabling authentication via cardspace to an Apache relying party. Since many sites use weak username/password combinations this creates a much stronger and flexible access control approach:

The whole cardspace processing can be a black box for the administrators

The module puts the attributes in the session. So if you have a PHP application, you can do the following to retrieve the attributes

$email = $_ENV[’auth_infocard_env_emailaddress’]
$ppid = $_ENV[’auth_infocard_env_privatepersonalidentifier’]

The same thing works in any other programming language, since they all give you access to your environment variables.

So this is pretty much as simple as it gets. I hope everyone with a product that runs on Apache will look at this.

But wait! There’s more! When I wrote to Ashish to congratulate him on this development, he added:

We also have a .jar file for java that serves the similar purpose (we internally refer it as the cardspace-magic.jar and we will open source some day). Same idea…drop the .jar file in, then:

xmltoken in -> attribute’s map out

So if you use Java, you can go that way too.

This is very cool stuff -- real enabling technology for building stronger distributed apps.

Build Security Into Your Web Apps and Web Services

Here is the list of public web application and web services security sessions starting this March in Chicago, San Jose, and coming to other cities near you...(assuming you live in NYC, DC, LA, or Boston that is). I am teaching these in conjunction with Aspect Security who are some of the primary contributors/founders/energizer bunnies behind OWASP. Brief Description of the courses

Building and Testing Secure Web Applications

The course starts with a module that demonstrates just how insecure most web applications are. It demonstrates how hackers are able to attack web applications, and what common vulnerabilities they exploit. The next modules detail specific security areas, discussing the foundational principles and best practices, and review code examples of design patterns for solutions.

SOA, Web Services and XML Security

Focused on Web Services and XML attack patterns; using WS-Security, SAML, XML Encryption and XML Digital Signature; Identity services and federation with SAML; Hardening Web Services; Input validation for Web Services; Integrating Web Services securely with backend resources and applications using WS-Trust For more details, dates and registration see below.

Location	Dates	Class 1	Class 2
Chicago, IL (downtown)	March 6-8	Building and Testing Secure Web Applications	SOA, Web Services, and XML Security
San Jose, CA (downtown)	March 20-22	Building and Testing Secure Web Applications	SOA, Web Services, and XML Security
New York City, NY (downtown)	April 17-19	Building and Testing Secure Web Applications	SOA, Web Services, and XML Security
Columbia, MD (In conjunction with WSSC Conference)	May 7	Foundations of Web Application Security	SOA, Web Services, and XML Security
Boston, MA (in Burlington)	May 15-18	Secure Coding for .NET	SOA, Web Services, and XML Security
Los Angeles, CA (near LAX)	June 12-15	Secure Coding for Java EE	SOA, Web Services, and XML Security
Northern VA (near Dulles)	July 17-19	Building and Testing Secure Web Applications	SOA, Web Services, and XML Security

More details are here.