Project Geneva – Part 1

I always want my blog to be about ideas, not the specific products I work on. 

But I thought it might be useful to make a bit of an exception in terms of sharing the announcements I made this week at the Microsoft Professional Developers Conference in Los Angeles.  I'm hoping this might help others in the industry understand exactly what we at Microsoft been able to accomplish around identity, what's left to do, and where we think we're going.

A number of people have told me that one of the conclusions they drew from the presentation is that when it comes to identity,  big, synergistic, cross-industry things are happening.   I liked that.

Not random things, not proprietary things, not divisive things.  But initiatives that further our collaboration, open standards, user choice and control and the “identity metasystem” many of us believe in so strongly, even if we call it by different names. 

I thought it might help, in particular, to share the conversation we are having with our developers.  This set of posts is intended as a bit of a look behind the curtain – or rather, as pulling back the curtain to show there is no curtain, if you will.  My presentation, which is on video here, went like this…

The first lines of every application

Whether you are creating serious Internet banking systems, hip new social applications, multi-party games or business applications for enterprise and government, you need to know something about the person using your application. We call this identity.

There is no other way to shape your app to the needs of your users, or to know how to hook people up to the resources they own or can share.

I want to be clear. Knowing “something” doesn't mean knowing “everything”.  We want to keep from spewing personal information all over the Internet.  It means knowing what’s needed to provide the experience you are trying to create.

This might sometimes include someone’s name. Or knowing they are really the person with a certain bank account.

Or it might just involve knowing that someone is in a certain role. Or in a certain age bracket.

It also might simply be a question of remembering that some user prefers Britney Spears to New Kids on the Block or Eminem.

Identity Turbulence

But getting identity information is one of the messiest aspects of application development. People are up to their necks in passwords. They use many different mechanisms to establish identity, and its getting worse.

One of my good friends at Microsoft is in charge of the identity aspects of one of our flagship apps. Let’s call him Joe .

He started years ago by building in support for usernames and passwords.  He was supposed to finish up within a few weeks, but soon found he needed a second project to build in better password reset and account management.

This soon worked pretty well, but when presented to customers, no one would deploy in large numbers unless he added a help desk component – so he did.

Then as Active Directory started gaining critical mass, he needed to set up a project to integrate with Active Directory.  When that was finished, the large sites wanted to use AD with multiple forests, and that involved a complete rewrite…

Next, people wanted to use the app outside the firewall, so he needed to add One Time Password (OTP) support. Supporters of Smart Cards were adamant that if OTP was supported, smartcards should work too.

Joe was just pretty much ready to return to his “core work” when he was asked to support SAML. He hadn't even finished his initial investigation of this when people started asking for OpenID support too.  Plus he needed to integrate with another software product by a different vendor  – who used a completely different and proprietary approach to identity.

As he was looking at all this he was hit by phishing attacks. That brought about a whole new round of security reviews – one for every one of the projects just discussed.

Now Joe has realized that his application has to be easily hostable in the cloud as well as work on-premise. And it needs to support delegation so it can access other services on behalf of his users…

So you’ll understand that he really wants and needs a better way. He wants to focus on the core values of his app, not the changing trends in identity.

Claims-based Access

 As we understood more about these problems, and the hardships they were causing developers, we started work on a way to insulate the application from all these issues.

Our goal? You – the developer – would write the application once and be done, yet it would support all the identity requirements customers have as they host it in different environments.

This was the same kind of problem we had in spades in the early days of computing. Back then, you needed to write separate code for each type of disk drive you wanted to support. There was no end to it. If you didn’t support the new drives you’d lose part of your market. So we needed the idea of a logical disk that was always the same.

We can now do the same thing around identity. We use what we call the Claims Based model.

A claim is a statement by one subject about another subject. Examples: someone's email address, age, employer, roles, custumer number, permission to access something.  There are no constraints on the semantics of a claim.

The model starts from the needs of the application:  you write your application on the assumption you can get whatever claims you need.

Then there is a standards-based architecture for getting you those claims. We call it the Identity Metasystem – meaning a system of identity systems. 

 

Here’s how the architecture works. As I said, the application is in control. It specifies the kinds of claims it requires. The claims providers support protocols for issuing claims. You can also pop in claims providers that translate from one claim to another – we call this claims transformers. That makes the system very flexible and open.

The technical name for a claims provider is a “Security Token Service”. You’ll see the abbreviation STS on upcoming slides.

The important thing here is that all existing identity mechanisms can be represented through claims and participate in the metasystem. As an app developer, you just deal with claims. But you get support for all permutations and combinations without getting your hands dirty or even thinking about it.

I say “all” to emphasize something – the open nature of this system. It accepts and produces identities from and for every type of platform and technology – no walled gardens.

You can choose to get your identity from anywhere you wish.  You can choose any framework to build your app.  You can choose to use any client or browser.

What's involved for the developer?

Let me give you an example.  I'll peek ahead and show you how the claims-based model is used in the Geneva Framework – new capabilities within .NET.  Other frameworks would have similar capabilities, though we think our approach is especially programmer-friendly. 

Basically, to answer the “Who are you?” question, you write your app as per normal, and simply add this extra configuration to you app.config file: 

(There are a couple of more cut-and-paste lines needed, to make sure some modules are included, but otherwise that’s it.)

Now, when a user hits your app, if they haven't been authenticated yet, they will get automatically redirected to the claims provider at https://sts1.contoso.com/FederationPassive to pick up their claims.  The claims provider will get your user to authenticate, and if all goes well, will redirect her back to your application with her identity set, and any necessary claims available to your program.  In other words, with zero effort on your part, no unauthenticated user will ever hit your app.  Yet you are completely free to point your app at any claims provider on any platform made by any vendor and located anywhere on the Internet.

To drill into the actual claim values, you use a technique like this:

You’ll see the Thread has a Current Principal, and the Principal has an Identity, so you get a Claims Identity interface as shown, then cycle through the claims or pull out the one you need.  In this case, it is the claim with the type of “role” – in the the enum MyClaimTypes.Role…

If you are an application developer, we've already come to the big takeaway of this presentation.  You can get up and go home now.  Everything else I’m going to show you is just to give you a deeper understanding of all the many use cases and scenarios that can be supported through these mechanisms.

Again, the claims shown in this example are implemented through well accepted industry standards. The same code works with claims that come from anywhere, any platform, any vendor, any operating system, any cloud provider.

Solving problems with claims

{In the next segment, I'll share the ideas I presented to my developer audience about how they could use claims to solve concrete problems.}

 

Kim Cameron's excellent adventure

I need to correct a few of the factual errors in recent posts by James Governor and Jon Udell.  James begins by describing our recent get-together:

We talked about Project Geneva, a new claims based access platform which supersedes Active Directory Federation Services, adding support for SAML 2.0 and even the open source web authentication protocol OpenID.

Geneva is big news for OpenID. As David Recordon, one of the prime movers behind the standard said on Twitter yesterday:

Microsoft’s Live ID is adding support for OpenID. Goodbye proprietary identity technologies for the web! Good work MSFT

TechCrunch took the story forward, calling out de facto standardization:

Login standard OpenID has gotten a huge boost today from Microsoft, as the company has announced that users will soon be able to login to any OpenID site using their Windows Live IDs. With over 400 million Windows Live accounts (many of which see frequent use on the Live’s Mail and Messenger services), the announcement is a massive win for OpenID. And Microsoft isn’t just supporting OpenID – the announcement goes as far as to call it the de facto login standard [the announcement actually calls it “an emerging, de facto standard” – Kim] 

But that’s not what this post is supposed to be about. No I am talking about the fact [that] later yesterday evening Kim hacked his way into a party at the standard using someone else’s token!  [Now this is where I think some “small tweaks” start to be called for… – Kim]

It happened like this. I was talking to Mary Branscombe, Simon Bisson and John Udell when suddenly Mary jumped up with a big smile on her face. Kim, who has a kind of friendly bear look about him, had arrived. She ran over and then I noticed that a bouncer had his arm across Kim’s chest (”if your name’s not down you’re not coming in”). Kim had apparently wandered upstairs without getting his wristband first. Kim disappeared off downstairs, and I figured he might not even come back. A few minutes later though and there he was. I assumed he had found an organizer downstairs to give him a wristband… When he said that he actually had taken the wristband from someone leaving the party, and hooked it onto his wrist me and John practically pissed our pants laughing. As Jon explains (in Kim Cameron's Excellent Adventure):

If you don’t know who Kim is, what’s cosmically funny here is that he’s the architect for Microsoft’s identity system and one of the planet’s leading authorities on identity tokens and access control.

We stood around for a while, laughing and wondering if Kim would reappear or just call it a night. Then he emerged from the elevator, wearing a wristband which — wait for it — belonged to John Fontana.  Kim hacked his way into the party with a forged credential! You can’t make this stuff up!

While there is certainly some cosmic truth to this description, and while I did in fact back away slightly from the raucus party at the precise moment James says he and Jon “pissed their pants”, John Fontana did NOT actually give me his wristband.  You see, he didn't have a wristband either. 

So let's go through this step by step.  It all began with the invite that brought me to the party in the first place:

As a spokesperson for PDC2008, we’re looking forward to having you join us at the Rooftop Bar of the Standard Hotel for the Media/Analyst party on October 27th at 7:00pm

This invite came directly from the corporate Department of Parties.

I point this out just to ward off any unfair accusations that I just wanted to raid the party's immense Martini bar. Those who know me also know nothing could be further from the truth. You have to force a Martini into my hands.  My attendance represented nothing but Duty.  But I digress.

Protocol Violation

The truth of the matter is that I ran into John Fontana in the cafe of the Standard and we arrived at the party together.  He had been invited because this was, ummm, a Press party and he was, ummm, Press. 

However, it didn’t take more than a few seconds for us to see that the protocol for party access control had not been implemented correctly.   We just assumed this was a bug due to the fact that the party was celebrating a Beta, and that we would have to work our way past it as all beta participants do. 

Let’s just say the token-issuing part of the party infrastructure had crashed, whereas the access control point was operating in an out-of-control fashion.

Looking at it from an architectural point of view, the admission system was based on what is technically called “bearer” tokens (wristbands). Such tokens are NOT actually personalized in any way, or tied to the identity of the person they are given to through some kind of proof. If you “have” the token, you ARE the bearer of the token.

So one of those big ideas slowly began to take root in our minds.  Why not become bearers of the requisite tokens, thereby compensating for the inoperative token-issuing system?

Well, at that point, since not a few of the people leaving the party knew us,  John and I explained our “aha”, and pointed out the moribund token-issuing component.  As is typical of people seeing those in need of help, we were showered with offers of assistance.

I happened to be rescued by an unknown bystander with incredibly nimble and strong fingers and deep expertise with wristband technology.  She was able to easily dislodge her wristband and put it on me in such a way that it’s integrity was totally intact. 

There was no forged token.  There was no stolen token.  It was a real token.  I just became the bearer.

When we got back upstairs, the access control point evaluated my token – and presto – let me in to join a certain set of regaling hedonists basking in the moonlight.  

But sadly – and unfairly –  John’s token was rejected since its donor, lacking the great skill of mine, had damaged it during the token transplant.

Despite the Martini now in my hand, I was overcome by that special sadness you feel when escaping ill fate wrongly allotted to one more deserving of good fortune than you.  John slipped silently out of the queue and slinked off to a completely different party.

So that's it, folks.  Yet the next morning, I had to wake up, and confont again my humdrum life.  But I do so inspired by the kindness of both strangers and friends (have I gone too far?)

 

The Emperor's new clothes

The UK's Register has been running a a series of articles by John Leyden  (here, here and here) about Verified By Visa. (VByV)  Verified By Visa uses the same kind of “site redirection” I've written about many times with respect to OpenID and other password-based federation technologies – but in this case it is a banking password that can be stolen.

The phishing scenario is simple enough.  If you happen onto an “evil” site and are tricked into purchasing something, it can “misdirect” your browser to a counterfeit VByV signon page.  As John explains, you have little chance, as a user, of knowing you are being duped, but once you enter your password it is available to the evil site for both instant use an future reuse.  Those familiar with this site will understand that this is yet another example of an attack that cannot be made against Information Card users.

Beyond focussing attention on the phishing problems inherent in “site redirection” approaches, John argues that the system – though claiming to be more secure – is actually just as vulnerable as non-VByV mechanisms.  He then argues – and I have know knowledge as to whether this is the case – that the false claims about increased security are being used to reject complaints by end-users about irregularities and fraudulent purchases made in their name.  If that were true, it would be scandalous.

Friends, this is a case of “The Writing on the Wall”.  I think people in the industry should see John's work as a sign of what's to come.   He is the guy in the fable who is shouting out that “the Emperor has no clothes!”  And he's doing it cogently to the wide readership of the Register.

If I were an advisor to the emperor at this point I would insist on two things: 

  1. admit the vulnerability of all systems based on “site redirection”; and
  2. start getting into phishing-resistant technologies like Information Cards while one's modesty can still be protected.

John makes his points without the stench of jargon.  In spite of this, North American readers will require a dictionary to follow what he's saying (I did).  I'm talking here about a dictionary of British idioms (thanks to my friend Richard Turner for boosting my vocabulary on this one) :

punter n guy. A punter is usually a customer of some sort (the word originally meant someone who was placing bets at a racecourse)…

To see a bit of what mainstream press worldwide will be writing about as the paucity of redirection technology for long-tail scenarios is concerned, I do suggest looking first hand at these articles.  One small taste:

Both Verified by Visa (VbyV) and MasterCard's equivalent SecureCode service are marketed as offering extra security checks to online purchases. Importantly, the schemes also transfer liability for bogus transactions away from merchants who use the system back towards banks (and perhaps ordinary e-commerce punters).

Online shoppers who buy goods and service with participating retailers are asked to submit a VbyV or SecureCode password to authorise transactions. These additional checks are typically submitted via a website affiliated to a card-issuing bank but with no obvious connection to a user's bank.

Punters aren't informed up front that a merchant has signed up to Verified by Visa. Sites used to authenticate a VbyV or SecureCode password routinely deliver a dialogue box using a pop-up window or inline frame, making it difficult to detect whether or not a site is genuine.

The appearance of phishing attacks hunting for Verified by Visa passwords are among the reasons some punters are wary of the technology.

Once obtained by fraudsters, either by direct phishing attack or through other more subtle forms of social engineering trickery, VbyV login credentials make it easier for crooks to make purchases online while simultaneously making it harder for consumers to deny responsibility for a fraudulent transaction…

The little-publicised mandatory use of the technology by some banks means that those with reservations have an uphill struggle to opt out of the scheme…

Verified by Visa and Mastercard SecureCode are there purely to protect the banks, not the card holder. They offer zero additional protection to the consumer, but allow the bank to claim that transactions using purloined credit card credentials were really made by the card holder. It is as simple as that.

[More here}.

 

IIW 2008B November 10-12 in Mountain View

The next Internet Identity Workshop (IIW) is coming up in November.  Identity Woman Kaliya and Phil Windley do a great job running this, and I did a double take reading Kaliya's list of what was accomplished there.  It really happened.

If you attend, you'll meet people thinking deeply about identity from a hundred points of view – and doing great software.   Here's Kaliya's description:

The community that comes together at the workshop is really amazing.  It is a working meeting for a range of groups focused on the technical, social and legal issues arising with the emergence identity, relationship and social layer of the web. The key thought leaders in the area are all there in a highly interactive environment.

We have been focused on “user-centric identity” – considering how end-users, regular people, can manage their own identity across the range of websites, services, companies and organizations that they belong to, purchase from and participate with.

A lot has happened since we first met in the fall of 2005 in Berkeley:

  • We have several foundations that have formed around key technologies – OpenID and Information Cards.
  • LIberty Alliance continues to be actively involved in the community
  • OASIS TC's have started actively participating.  
  • The Vendor Relationship Management project has sprung up out of the community continues to evolve. 
  • OSIS – (Open Source Identity Systems) was founded at IIW and is working on its 4th major interop event happening at DIDW next week (#3 was at RSA in the spring).

 As a community we have been exploring these kinds of questions:

  • How are social networking sites and social media tools applying user-centric identity?
  • What are the open standards to make it work? (identity and semantic)
  • What are technical implementations of those standards?
  • How do different standards and technical implementations interoperate?
  • What are the new social norms and legal constructs needed to make it work?
  • What tools are needed to make it usably secure for end-users?
  • What are the businesses cases / models that drive all this?

 You can check out our community aggregate blog http://www.planetidentity.org

Here is my blog on the conference http://www.identitywoman.net/?p=784

 Who comes to  IIW?:

  • Anyone interested in identity (user profiles, social linking, user history & metadata etc) on the web and in digital systems. 
  • Entrepreneurs  who are working companies about people and their identities online – profiles, social linking, group formation. Basically those doing ANYTHING with the word SOCAIL in it.
  • Product Managers who are trying to figure what to do now and plan for interms of user-identity and information sharing in your product. 
  • Engineers/Programmers who have to implement the emerging standards that are covered at IIW.
  • Researchers/Academics studying identity online. 
  • Lawyers who are interested in end-user agreements and how new technologies change/improve how people interact with companies.
  • Sociologists, Anthropologists who are considering online life and the implications of identity online.

This is a conference where you get out of it what you want.  If you have something to present you are most welcome to. If you have questions you need answers to you can find them.

You can read what community members have said about the quality of the event.

Cost:

The event is VERY affordable for a 2.5 day high quality conference with the leading professionals in the industry.

  • Students – $50
  • Independents (small startups, nonprofits)- $200
  • Corporate – $350

 

The Identity Metasystem and its Identity Selectors

Paul Madsen at ConnectID makes a good point in his “Could someone hand me that hammer please?

I have a dead horse here that needs some beating.

Does  ‘identity metasystem’ not imply “a pluralism of operators and technologies”? Isn't this even almost a law?

If so, should a TC focused on a single (albeit important) identity technology claim within its name the ‘meta’ scope?

The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards

The IMI TC's mandate respects the ‘pluralism of operators’ required by the metasystem definition, but not the other piece.

NB: Any comment that includes any combination of  ‘forgot SAML token’ will be summarily rejected.

 

Metasystem and Identity Selector

Paul is completely right that the Identity Metasystem is a unifying model intended to bring together many contributing technologies – including Kerberos, PKI, browser-only federation protocols like SAML, WS-Security, WS-Trust and lightweight protocols like OpenID.  And in fact, reaching across this diversity is the most important thing about it.  Breadth is what allows us, as an industry, to create “one identity model” in terms of application development, deployment and most important, user experience.

To make this vision a reality, we need a component of the metasystem that has been missing: a common “Identity Selector”  (early examples being CardSpace and DigitalMe). 

Clearly such an important component needs to evolve in the context of an international standards body, so the announcement of the new OASIS Technical Committee dedicated to Information Cards and their interoperability is an important milestone:

Boston, MA, USA; 23 September 2008 — OASIS, the international open standards consortium, has formed a new group to enable the use of Information Cards to universally manage personal digital identities. The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards. A rapidly-developing, Web 2.0-friendly method for shared light authentication, Information Cards let people authenticate themselves on multiple web sites without maintaining passwords for each site.

But back to the name 

While I think Information Cards are beneficial to the whole metasystem, they are not themselves the metasytem, and don't encompass all aspects of its interoperability. 

For this reason, I don't personally think the OASIS committee's name is currently quite right.

I've never personally participated in OASIS or any other standards body (I have great respect for those who do.)  So I have no idea whether it is possible to tweak a name once a committee is formed.  If it didn't turn into a major time-waster, I think doing so would show everyone's respect for all the other contributions being made to the metasystem.  I would prefer a name that is more technically specific, like the OASIS Identity Selector Interoperability Technical Committee (ISI).

The people who put in the effort to set up the committee and come up with a name will rightly say, “I wish you had given us that feedback earlier” – and I accept that criticism.  Maybe I have missed my opportunity to provide feedback.  Basically, I was sufficiently excited about the emergence of the committee, and convinced that the Identity Selector did contribute to Metasystem Interoperability, that the potential issues with the name didn't jump out at me. 

And now to Occam

And now for something completely different.  In a recent post Paul also reveals the origins of the third law of identity, and makes a great connection:

“William of Occam was a 14th century English philosopher, best know for his ‘principle of parsimony‘ in comparing different explanations for some phenomena.

entia non sunt multiplicanda praeter necessitatem

“When translated and applied to identity, it's clear that Kim's Law 3 was preempted by some 700 years

entities must not be multiplied beyond necessity

Are Countrywide's systems designed around need to know?

I'm mad as hell and I'm not taking it any more

It was inevitable, given how sloppy many companies are when handling the identity of their customers, that someone would eventually steal all my personal information.  But no matter how much science you have in your back pocket, it hurts when you get slapped in the face.

The theory is clear:  systems must be built to withstand being breached.  But they often aren't.

One thing for sure: the system used at Countrywide Mortgage was so leaky that when I phoned my bank to ask how I should handle the theft, my advisor said, “I don't know.  I'm trying to figure that out, since my information was stolen too.”  We commiserated.  It's not a good feeling.

And then we talked about the letter.

What a letter.  It is actually demented.  It's as though Countrywide's information systems didn't exist, and weren't a factor in any insider misbehavior. 

I agree there was a bad employee.  But is he the only guilty party?  Was the system set up so employees could only get at my personal information when there was a need to know

Was the need to know documented?  Was there a separation of duties?  Was there minimization of data?  Can I see the audit trails?  What was going on here?  I want to know.

My checks rolled in to Countrywide with scientific precision.  No one needed to contact me through emergency channels.  Why would anyone get access to my personal information?  Just on a whim?  

How many of us were affected?  We haven't been told.  I want to know.  Iit bears on need to know and storage technologies.

But I'm ahead of myself.  I'll share the letter, sent by Sheila Zuckerman on behalf of “the President” (“President” who??).

We are writing to inform you that we recently became aware-that a Countrywide employee (now former) may have sold unauthorized personal information about you to a third party. Based on a joint investigation conducted by Countrywide and law enforcement authorities, it was determined that the customer information involved in this incident included your name, address, Social Security number, mortgage loan number, and various other loan and application information.

We deeply regret this incident and apologize for any inconvenience or concern it may cause you. We take our responsibility to safeguard your information very seriously and will not tolerate any actions that compromise the privacy or security of our customers’ information. We have terminated the individual's access to customer information and he is no longer employed by Countrywide. Countrywide will continue to work with law enforcement authorities to pursue further actions as appropriate.

I don't want to hear this kind of pap.  I want an audit of your systems and how they protected or did not protect me from insider attack.

If you are a current Countrywide mortgage holder, we will take necessary precautions to monitor your mortgage account and will notify you if we detect any suspicious or unauthorized activity related to this incident. We will also work with you to resolve unauthorized transactions on your Countrywide mortgage account related to this incident if reported to us in a timely manner.

I find this paragraph especially arrogant.  I'm the one who needs to do things in a timely manner although they didn't take the precautions necessary to protect me. 

As an additional measure of protection, Countrywide has arranged for complimentary credit monitoring services provided by a Countrywide vendor at no cost to you over the next two years. We have engaged ConsumerInfo.com, Inc., an Experian® Company, to provide to you at your option, a two-year membership in Triple Advantage Credit Monitoring.  You will not be billed for this service. Triple Advantage includes daily monitoring of your credit reports from the three national credit reporting companies (Experian, Equifax and TransUnion®) and email monitoring alerts of key changes to your credit reports.

Why are they doing this?  Out of the goodness of their hearts?  Or because they've allowed my information to be spewed all over the world through incompetent systems?

To learn more about and enroll in Triple Advantage, log on to www.consumerinfo.com/countrywide and complete the secure online form. You will need to enter the activation code provided below on page two of the online form to complete enrollment. If you do not have Internet access, please, call the number below for assistance with enrollment.   You will have-90 days from the-date of-this letter-to-use the code to activate the credit monitoring product.

Borrower Activation Code: XXXXXXXXX

And now the best part.  I'm going to need to hire a personal assistant to do everything required by Countrywide and still remain employed:

In light of the sensitive nature of the information, we urge you to read the enclosed brochure outlining precautionary measures you may want to take. The brochure will guide you through steps to:

  • Contact the major credit bureaus and place a fraud alert on your credit reports;
  • Review your recent account activity for unauthorized charges or accounts;
  • Be vigilant and carefully review your monthly credit card and other account statements over the next twelve to twenty-four months for any unauthorized charges; anTake action should any unauthorized activity appear on your credit report.

I need more information on why I only need to be vigilant for twelve to twenty-four months, when, thanks to Countrywide, my personal information has spilled out and I have no way to get it back!

We apologize again that this incident has occurred and for any inconvenience or worry it may have caused.  If you have questions, please call our special services hotline at 1-866-451-5895, and a specially trained representative will be ready to assist you.

Sincerely,

Sheila Zuckerman
Countrywide Office of the President
Enclosure

O.K.  This is going to be a long process.  It drives home the need for data minimization.  It underlines the need for stronger authentication.  But EVERY case like this should make us deeply question the way our systems are structured, and ask why there are no professional standards that must be met in protecting private information.

When a bridge collapses, people look into the why of it all.

We need to do that with these identity breaches too.   As far as I'm concerned, Countrywide has a lot of explaining to do.  And as a profession we need clear engineering standards and ways of documenting how our systems are protected through “need to know” and the other relevant technologies.

Finally, we all need to start making insider attacks a top priority, since all research points to insiders and our number one threat.