Network World senior editor John Fontana has provided this guest blog to Microsoft Subnet. He is reporting on the IDG editors meeting with Microsoft in Redmond on April 23. He writes: Microsoft’s Scott Charney, corporate vice president for Trustworthy Computing (pictured right), came by in the afternoon and provided the IDG editors with a fascinating college-like lecture on how to get trustworthy computing to the Internet. (And I’m not being facetious — it really was interesting.)
Now we can all chuckle over trustworthy, Microsoft and security in the same sentence. In fact, Charney said his friends laughed six years ago when he told them he was coming to Microsoft to do security. “They thought it was hysterically funny,” he said. But he said that the image problem is not a technical one but a business process issue and this comes from a man that is no marketing/vision wonk. His background is impressive along with his ability to clearly explain the security problems and paths/challenges toward solutions. (Why doesn’t Microsoft put these gems on stage at major conferences?).
Charney served as chief of the Computer Crime and Intellectual Property Section (CCIPS) in the Criminal Division of the U.S. Department of Justice. He helped prosecute nearly every major hacker case in the United States from 1991 to 1999. And he has even more credentials in fighting cyber crime. (See the rest of his bio for yourself, if you want. )
Rather than me providing a synopsis of his message, it is worth reading the white paper (Establishing End-to-End Trust) he presented at the recent RSA conference. The paper, however, is 23-pages long, so here’s a portion of it for you to get a feel for the idea of Microsoft’s end-to-end trust. Turn the page to see the five components that create trust …
See also:
Podcast: Microsoft security? Experts applaud it
VII. The Path Forward
There are essentially five major security components required to help facilitate trust, whether the
“thing” being trusted is a person, device, operating system, software application, or piece of data. In
the discussion that follows, we only describe identifiers, authentication, authorization, access control,
and audit processes or services; we are not prescribing particular policies or mechanisms (e.g.,
enrollment mechanisms).
1. Identity Claims. Who does the person or what does the device or software claim to be? As a
starting point, someone may claim to be a given person (e.g., John Smith) or simply claim to
have a certain attribute (e.g., I am over 18 years of age). A device may claim to be an eBay
server or a router, and an application may claim to be a particular version of Microsoft Office
Word. The claim may also relate to source or integrity (this is a packet from an X Company
router, or this spreadsheet was sent from John and has not been altered since being sent).
An identity claim is, of course, only one part of the equation; in many contexts, reputation is
equally critical and (especially because it is hard to speak about identity in absolute terms)
will serve to add additional layers of assurance to an identity claim. This will be the case
regardless of which element in the stack the claim attempts to validate. Robust reputation
policies, processes, and systems will need to be built out to support the many trust decisions
people need to make. Put another way, if a person claims to be John Smith, but you have
never met John Smith before, the identification does not provide enough information to
warrant a trust decision. Thus, closely related to the issue of identity are other attributes that
are linked to that identity (e.g., past experiences, relationships, reputation).
2. Authentication. We must have mechanisms that allow identity claims to be verified. In the
physical world, we often turn to formal documents (John Smith may have a national identity
card, a passport, or a driver’s license) to verify identity, even if the item used was not created
for that purpose (e.g., a driver’s license may be used by a bartender to ensure someone is
old enough to purchase alcohol even though the intended purpose is to prove the right to
operate a vehicle). We also have people whose function it is to verify identity (e.g., the notary
public for documents, the Post Office for passport applications). There are clearly electronic
analogies; we may use certificates to identify a device, or digital signatures to identity the
author of software, and a root certificate for the organization verifying that claim.
Authorization policies. Assuming an identity is authenticated, there is some formal or informal
3.
policy that permits or prohibits activity based upon that authenticated identifier. Also of
importance is who gets to determine the policy.
Access control mechanisms. Consistent with policy, a person may request access to a
4.
resource (e.g., the liquor store in the physical world, or an e-mail account in an electronic
world). Access will be granted or denied based upon policy and verification of any necessary
attributes. At times, people may obtain access to resources without, or in excess of, authority,
thus potentially violating computer crime laws.
Audit. All the above (identity claim, proof of authentication, policies for authorization, request
5.
for access, decision on the request, and any unauthorized access attempts) must be
documentable, as opposed to documented. How much audit data is collected, retained,
From Microsoft’s white paper, Establishing End to End Trust
Go to the Microsoft Subnet home page for more news, blogs, podcasts.
More Microsoft Subnet blog posts:
New Microsoft virtualization tool coming soon Exchange and SharePoint to be revamped for multitenant versions Low-cost PCs and a lightbulb goes off in Redmond Microsoft attempts to appease its channel while moving forward with servicesMicrosoft’s Salesforce.com “killer” offers killer pricing XP SP3 available to volume license holdersMore info on Office Genuine Advantage notificationAll Microsoft Subnet blog postsSign up for the bi-weekly Microsoft newsletter. (Click on News/Microsoft News Alert.)
