Cisco Blogs


Cisco Blog > Government

Are smart cards heading the way of video recorders?

I read an article recently discussing the advantages and disadvantages of smartcards. I know that there have been quite a few distributed, but it seems to me that the adoption rate and the length of time they have been available are a bit out of sync. I would have thought that we would have many more smartcards, used in more places, being as they werer actually invented in 1968, and were widely used in French pay phones starting in 1983.

Read More »

Tags: , , , , , , ,

Even Security Administrators Deserve a Break – Part 2 of 2

June 23, 2011 at 8:27 am PST

In my last post on this topic, I highlighted just how true the words “Work is no longer a place you go, but what you do” really are. We now have the ability to work anytime, anywhere, using any device. As easy as this has made the lives of workers all over the world, it’s made the lives of security administrators immensely difficult. Providing secure access to the corporate network in a borderless world, while still somehow keeping out the bad stuff, has caused traditional security policies to become increasingly difficult to configure, manage, and troubleshoot – the source of inordinate amounts of pain for security administrators.

That’s why Cisco has introduced identity-based firewall security as a new capability of the ASA platform. As the first installation of what will soon become full context-aware security, identity-based firewall security enables security administrators to utilize the plain language names of users and groups in policy definitions. Rather than authoring and managing the growing list of IP addresses to cover every possible location, device, or protocol that may be required for secure access to the network, identity-based firewall security enables security administrators to grant access to “Jeff.” Regardless of where I am or what I’m using for access, I’m still Jeff… so in the simplest case, my administrator can literally write one policy to provide “Jeff” access to the corporate network, rather than six different IP addresses for all the instantiations of Jeff.

Read More »

Tags: , , , ,

Establishing Trust in the NSTIC

This is part of an ongoing series on the National Strategy for Trusted Identities in Cyberspace. The introduction to this series can be found here.

The National Strategy for Trusted Identities in Cyberspace (NSTIC) proposes a large ecosystem of identity providers, attribute providers, and relying parties that must establish trust with each other in various ways. NSTIC requires various types of trust within the identity ecosystem. These include:

  • Users must trust that their Identity Provider will manage their credentials securely and in their best interest.
  • Relying Parties must trust in the attributes provided by Attribute Providers.
  • Attribute Providers must trust Identity Providers and Relying Parties to handle attributes, which may include proprietary data such as credit scores, in accordance with their terms of use.
  • Relying Parties must trust Identity Providers to provide the requested strength of authentication and to manage credentials and attributes correctly.

The term “federated identity” is widely used to refer to identity systems that span multiple organizations, each of which maintains its own identity information. That arrangement is typically used between an enterprise and its business partners, such as contract manufacturers, channel partners, and consulting firms. Trust is established individually with each. A fully meshed federation of n participants would require n(n-1) such agreements, which does not scale well beyond small federations, especially considering that these agreements often take the form of contractual negotiation between each party.

Read More »

Tags: , , ,

Adapting Levels of Assurance for the NSTIC

This is part of an ongoing series on the National Strategy for Trusted Identities in Cyberspace. The introduction to this series can be found here.

One of the goals of the National Strategy for Trusted Identities in Cyberspace (NSTIC) is to support a wide range of use cases. These might include everything from low-value purchases to making adjustments to critical infrastructure, like power systems, where someone might get hurt if an unauthorized action takes place.

Read More »

Tags: , , , ,

Credential and Attribute Providers in the NSTIC

This is part of an ongoing series on the National Strategy for Trusted Identities in Cyberspace. The introduction to this series can be found here.

The National Strategy for Trusted Identities in Cyberspace (NSTIC) describes two types of intermediaries between subjects (users) and relying parties: identity providers and attribute providers. This is a separation not frequently found in identity systems. In order to emphasize this distinction, I often use the term “credential provider” or “authentication provider” rather than identity provider to refer to a service that provides authentication services and makes assertions resulting from authentication but does not directly provide attributes about the subject.

A credential provider can be thought of as a key cabinet. The subject authenticates to the credential provider in order to “unlock” the cabinet of credentials. As with a physical key cabinet where different keys inside are used for different things, the credential provider serves different credentials to different services. Ideally, the identifiers used for each of these services would be different; a good identifier is also opaque, meaning that the identifier itself provides no additional information about the subject. Provided that the choice of credential provider itself does not reveal significant information about the subject, a subject can be generally pseudonymous with respect to the relying party until the subject authorizes the release of identifying attributes.

Read More »

Tags: , , , ,