Leveraging existing work to deliver on NSTIC

I was fortunate enough to sit in on a session at the Department of Defense IPM conference a couple of weeks ago that was given by Andy Ozment, the White House Director for cybersecurity policy. Andy was speaking on the just released NSTIC (National Strategy for Trusted Identities in Cyberspace).

Andy's talk was a general one that discussed the background, need, plan in general and the intended benefits. I will be upfront here in that I believe that NSTIC is a good idea, especially when combined with other initiatives that are being undertaken inside the Federal government today. NSTIC as a program is intended to move the bar forward by incentivizing industry to provide a better credential set to their users. Options will allow some vendors to have a highly interoperable credential that addresses a very broad range of services and these implementations will be created following guidelines that are created by the government and industry. This truly becomes a public-private initiative, government providing some base requirements to ensure interoperability and improved security and then providing a framework for credential providers and relying parties to use these credentials. At the same time the government will provide seed money for pilot programs where interoperability with government applications becomes the carrot for end users to also get involved.

Again I think this is a great idea and we need to make sure that this initiative leverages existing work that has been done and is underway. The existing PIV card is a good example of a federated credential and it's extension into PIV-I broadens the user base for that federation. The PIV and DOD CAC programs today cover somewhere less than a few million users, PIV-I is targeted at organizations that have a need for a well defined credential for physical and logical access that also allows for a high level of interoperability. This type of credential is well suited for medium to large corporations, first responders in all market segments and state and local governments. That is a very large user population.

Of course PIV and PIV-I are not credentials for the masses. Today people have varying levels of credentials that they use, some with a true identity linkage and others totally anonymous. Some of these credentials have second factor capabilities such as the ability to tie into Google Authenticator or tokens such as the eBay and PayPal tokens. As smartphones become more capable and secure we could also see expansion of the applications such as those offered by Visa and even Starbucks to capabilities that would allow interoperability with other relying parties.

The idea that a single relying party will accept credentials from multiple providers using multiple technologies may seem far-fetched but even today government applications such as NIH's PubMed allows use of different trust provider platforms for access to it's resources.

Of course as we extend the credential acceptance we need to remember that identification does not mean authorization. We need to make sure that while a federated identity makes things easy for the user, and in some regards easier for the relying party, since they do not need to be an identity provider as well, that we are aware that we need to know who we are letting perform transactions and why. Attribute exchange allows identity providers and relying parties to communicate to ensure that authorization decisions can be appropriately made at the relying party end. This capability could also allow for end users to better control what information they share with relying parties by giving them the ability to only release information in certain cases. Some examples - a blog I am commenting on does not need to know my real name; a online wine store does not need my birthdate only an assurance that I am 21. There are initiatives today, that I have previously discussed in other posts, that build the basis for this.

Again this is not a case of building something new but rather a case of taking what is out there, leveraging some updated policies and guidance and then architecting an interoperable system.

- Posted using BlogPress from my iPad

Rumblings in the identity world

These last few weeks have almost seemed like the coming of the apocalypse .... breaches at EMC opening vulnerabilities to SecurID tokens, someone taking control of a Comodo registration account and issuing certificates improperly, and a breach at Epsilon opening the door to mass phisihing attacks.

Of course these events have generated lots of press about the impacts of these events, including things like "The Public Key Infrastructure Under Siege" and many others. What I find interesting about much of the press is the very negative side of things, including the implications that the underlying technology is flawed.

Looking at each of these events points to a set of issues in implementation and relying party applications.

- The EMC breach was a result of an employee opening a file embedded in an email. Yes it was a zero-day attack but if the employee is receiving emails with attachments they need to be aware of the threat and take proper actions - such as validating the source email and mapping the message to the likelihood that the file is appropriate to come from that party. No technology involved here.
- The Comodo attack also likely involved a multi-step process with some malware allowing capture of the RA credentials. This is easily preventable by having RAs issued smart cards that ensure the authentication credentials cannot be removed from the card. In this case an attack needs to get at the card and the passphrase for card unlock.
- the Epsilon attack is still being evaluated but the message for the consumer is to be aware and smart. Do not click on links in messages that you are not confident in. If you deal with someone and get an email, purportedly from that company, then go direct to their website - do no use links in email. And when you go direct to the site make sure it is a protected site before giving up information.

Can we stop all attacks - the answer is no and likely that will always be true. So with that in mind let's be smart and let's make the end user smart through education. The messages need to be simple though:
- Do not click on links in emails unless you have very high confidence. Go direct to company websites rather than using links in email.
- When you go to company sites, look for green! That means look for companies that are using Extended Validation certificates whose validation includes turning the browser address bar green.
- Do not accept certificates where you need to imbed a new root unless it has come from an EV protected site. It opens you to long term vulnerabilities.

The education also extends to companies:
- Educate employees on the above.
- Review your logs regularly - daily for sensitive systems for those that are issuing credentials.
- If you are building software that uses Digital credentials such as PKI then implement complete solutions. NIST provide some test suites to test implementations.

These are just some starting points. The main element here is that the technology is not in itself broken but we as developers, users and relying parties need to make sure we are using it correctly. There are no silver bullets so let's make sure we educate people as to how they use the bullets they have.


- Posted using BlogPress from my iPad