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
Thursday, April 28, 2011
Wednesday, April 6, 2011
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
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
Friday, March 4, 2011
The move to the Cloud
It sometimes makes me smile when everyone starts talking about cloud computing. All the buzzwords are out there - no longer TLAs but now Four Letter Acronyms such as SaaS, IaaS, NaaS and dual meanings for these and more. Is SaaS software as a service or storage as a service? What we end up with are a few great ideas, some good ideas and then a whole lot of misunderstanding and what then become bad paths taken that end in poor implementations.
All of that being said cloud computing, as an idea, shared services that reduce implementation and operating costs in a standard way, is a great one. Honestly I use it every day - my Google services as one easy example.
Now that good Idea is gaining attention within the US Federal Government and I believe it is the right move - if attention is paid. Reduction of operating costs through consolidation of data centers is a prudent thing to be looking at. I know that the government knows how to protect resources so if they leverage that expertise then consolidation can be achieved with not just cost savings but in fact improved service and reliability of the infrastructure. To achieve this will take some push from Capitol Hill, OMB or maybe even the White House to ensure that implementations are not hindered by agency politics but I think that in today's environment of shrinking budgets this will be easier to deliver now than 10 years ago.
One of the other big considerations, of course, will be security. Again this is not a case of me believing that the government does not understand security but may instead be a case of ensuring that the implementation covers the areas of concern. In my eyes this includes things like:
- appropriate means of authentication based on the resource as well as the operational environment
- implementation of a open authorization model to consider government employees, contractors and non-governmental personnel with a need to access such as law enforcement and other first responders
- implementation of fraud detection within the transactional environment to ensure that information remains in control of the parties authorized to see and use it
- an understanding of the ability to open certain resources to the public using appropriate authentication means
These things, as you can see, are not technology specific but should be considered as part of the governments overall programs with regards to identity within the federal space as well as identity within the non-federal space such as that as defined by NSTIC. Of course as part of this there is also consideration to information sharing with other national partners.
This is a topic that has much interest to me so I will be following and discussing this a bit more in the near future.
- Posted using BlogPress from my iPad
All of that being said cloud computing, as an idea, shared services that reduce implementation and operating costs in a standard way, is a great one. Honestly I use it every day - my Google services as one easy example.
Now that good Idea is gaining attention within the US Federal Government and I believe it is the right move - if attention is paid. Reduction of operating costs through consolidation of data centers is a prudent thing to be looking at. I know that the government knows how to protect resources so if they leverage that expertise then consolidation can be achieved with not just cost savings but in fact improved service and reliability of the infrastructure. To achieve this will take some push from Capitol Hill, OMB or maybe even the White House to ensure that implementations are not hindered by agency politics but I think that in today's environment of shrinking budgets this will be easier to deliver now than 10 years ago.
One of the other big considerations, of course, will be security. Again this is not a case of me believing that the government does not understand security but may instead be a case of ensuring that the implementation covers the areas of concern. In my eyes this includes things like:
- appropriate means of authentication based on the resource as well as the operational environment
- implementation of a open authorization model to consider government employees, contractors and non-governmental personnel with a need to access such as law enforcement and other first responders
- implementation of fraud detection within the transactional environment to ensure that information remains in control of the parties authorized to see and use it
- an understanding of the ability to open certain resources to the public using appropriate authentication means
These things, as you can see, are not technology specific but should be considered as part of the governments overall programs with regards to identity within the federal space as well as identity within the non-federal space such as that as defined by NSTIC. Of course as part of this there is also consideration to information sharing with other national partners.
This is a topic that has much interest to me so I will be following and discussing this a bit more in the near future.
- Posted using BlogPress from my iPad
Wednesday, February 9, 2011
Traveling and Identity
I was reading an interesting article today from Aviation Week on airport security screening. Of course we all have heard about, and large numbers of us have complained about, the recent changes at the airport. We jockey lines to try and avoid the full body scanners and possible pat-downs. I know most people are not doing this to avoid security but to avoid embarrassment or at least perceived embarrassment. This article made me think more about identity and traveling and some of the work that is being done today to improve identity and authorization decisions within the government sector.
We all have heard that air travel is a privilege - one generated out of the convenience of time. I can go anywhere without having to fly - it just may take a lot longer. In that vein I begin to wonder if people are ready to accept the need for better identity assurance at a security screening checkpoint to make traveling easier and maybe safer. What if we had a card based credential that allowed a user to scan the credential prior to entering a metal detector? The credential would ideally carry the same level of assurance of any ICAO travel document and could be issued by a nation, such as a passport, or could be issued by the private sector. The traveller would scan their card immediately before entering the metal detector. While the traveller is passing through the scanning device an automated check of the credential would allow personnel to know if the credential presented was valid and combined with the visual check of the card would allow match of person to the credential. Using this combination could increase the level of assurance of identity of the traveller. If the credential does not properly validate then some additional screening could be performed.
If we take it one step further we could incorporate some of the work being done in the government with Backend Attribute Exchange, aka BAE, which would allow the system to reach back to the credential issuer or potentially a National Travel Blacklist, to see if there are any reasons to further screen the individual. These checks could be performed in seconds, the time it takes for a person to step through a metal detector and make it through the security area.
Of course in such a idealized system one would need to consider the issues of privacy and the need to ensure tracking information is not being maintained in the system. Integrity and availability of the system would be critical to ensure minimized additional screening. For the frequent, trusted, traveler this may mean a faster and easier trip through security at the airport and could provide a basis for a system that adds to the security environment for all air passengers.
Something to think about.
- Posted using BlogPress from my iPad
We all have heard that air travel is a privilege - one generated out of the convenience of time. I can go anywhere without having to fly - it just may take a lot longer. In that vein I begin to wonder if people are ready to accept the need for better identity assurance at a security screening checkpoint to make traveling easier and maybe safer. What if we had a card based credential that allowed a user to scan the credential prior to entering a metal detector? The credential would ideally carry the same level of assurance of any ICAO travel document and could be issued by a nation, such as a passport, or could be issued by the private sector. The traveller would scan their card immediately before entering the metal detector. While the traveller is passing through the scanning device an automated check of the credential would allow personnel to know if the credential presented was valid and combined with the visual check of the card would allow match of person to the credential. Using this combination could increase the level of assurance of identity of the traveller. If the credential does not properly validate then some additional screening could be performed.
If we take it one step further we could incorporate some of the work being done in the government with Backend Attribute Exchange, aka BAE, which would allow the system to reach back to the credential issuer or potentially a National Travel Blacklist, to see if there are any reasons to further screen the individual. These checks could be performed in seconds, the time it takes for a person to step through a metal detector and make it through the security area.
Of course in such a idealized system one would need to consider the issues of privacy and the need to ensure tracking information is not being maintained in the system. Integrity and availability of the system would be critical to ensure minimized additional screening. For the frequent, trusted, traveler this may mean a faster and easier trip through security at the airport and could provide a basis for a system that adds to the security environment for all air passengers.
Something to think about.
- Posted using BlogPress from my iPad
Sunday, February 6, 2011
Mixed Messages
The beginning of this past week I was getting on a plane to head to the left coast when I saw, what I thought was, a good piece on Headline News on the National Strategy for Trusted Identity in Cyberspace aka NSTIC. It was a quick overview but they seemed to have gotten the message right - that it was an effort to get industry to improve the capabilities for online identity. The idea around NSTIC is that the government and industry would work together to define/refine standards to ensure that it was not a set of stovepipe identity solutions that could not interoperate; work together so that the systems would be secure; and to, in the process, protect privacy as appropriate.
I was somewhat encouraged - mainstream media had seemed to actually understand the effort .... and then a few hours later I saw the headline Why You Should Trust Apple More Than the U.S. Commerce Dept. With Your Universal Online ID
POP goes the bubble. Here we have someone writing for Fast Company proposing a corporately patented idea as the right approach. Now we know that as the standards evolve there will be patent issues and, as in the past, I expect them to be resolved for the greater good, but this article seems to suggest that Commerce is going to hold your identity and everything is in the governments control. This is not the vision of NSTIC that I see, or anyone that I know and work with sees.
If you want a vision of what NSTIC is look no further than the US Government employee ID, the PIV card. Here a standard was developed for internal government use. It had technical and policy aspects and required the use of Government run or Government contracted identity providers. But then industry realized that the technical specifications of the card provided a good base for non-governmental people. What happened next - well government and industry worked on refining the standard for non-governmental work. The identity issuers were now private industry. The card issuers we now private industry. The only thing the government did to stay involved was to crate a test program around the standard that would ensure that the credential could be trusted ... and PIV-I was born.
This is what NSTIC envisions - a public-private partnership where good standards are made better through joint discussion; testing programs are put in place to ensure that products and services meet a set of standards and private industry provides these products and services to the masses.
How hard is that to understand? I hope Fast Company spends some time researching so they can criticize where it is deserved.
- Posted using BlogPress from my iPad
I was somewhat encouraged - mainstream media had seemed to actually understand the effort .... and then a few hours later I saw the headline Why You Should Trust Apple More Than the U.S. Commerce Dept. With Your Universal Online ID
POP goes the bubble. Here we have someone writing for Fast Company proposing a corporately patented idea as the right approach. Now we know that as the standards evolve there will be patent issues and, as in the past, I expect them to be resolved for the greater good, but this article seems to suggest that Commerce is going to hold your identity and everything is in the governments control. This is not the vision of NSTIC that I see, or anyone that I know and work with sees.
If you want a vision of what NSTIC is look no further than the US Government employee ID, the PIV card. Here a standard was developed for internal government use. It had technical and policy aspects and required the use of Government run or Government contracted identity providers. But then industry realized that the technical specifications of the card provided a good base for non-governmental people. What happened next - well government and industry worked on refining the standard for non-governmental work. The identity issuers were now private industry. The card issuers we now private industry. The only thing the government did to stay involved was to crate a test program around the standard that would ensure that the credential could be trusted ... and PIV-I was born.
This is what NSTIC envisions - a public-private partnership where good standards are made better through joint discussion; testing programs are put in place to ensure that products and services meet a set of standards and private industry provides these products and services to the masses.
How hard is that to understand? I hope Fast Company spends some time researching so they can criticize where it is deserved.
- Posted using BlogPress from my iPad
Location:the stratosphere
Friday, January 28, 2011
Moving ahead with reduced identities
I had lunch last week with an old colleague. During the lunch we had a good chat on NSTIC. One of the points she brought up was the education aspect - the fact that to most people this whole cyber security thing is very foreign and that there are many things that exist today that people do not realize bring additional trust to what they do online.
I have been thinking about that for a while. Especially in relation to the work that I have been doing on what effectively is credential re-use. She was correct in that most people do not know to look for the green bar in the browser indicating the extra diligence to validate the site. I think that it is a case of people not knowing why it is there and what it brings. But I also think the same is true of identity re-use. I think people do it today and do not realize it.
Now I do not mean just the re-use of drivers licenses, Social Security numbers and the such but of online identities. I started to think about my own environment. I use my Google identity to use many things today - the normal Gmail, Calendar etc but also using it to log onto other applications on my iPad, laptop and Android phone. I use my OpenID to access ToodleDo and other sites and many applications that I use leverage SAML, Oauth and OpenID to allow me to take advantage of credential re-use. Of course in a lot of these cases I also see Facebook and Twitter options for login so I have to imagine that people are using these rather than create yet another account.
I think the strength and advantage of NSTIC is the possibility that in a few years I will be able to do all my online functions using a small set of identities. I may always have that Yahoo mail address so getting rid of all but one is unlikely but if I can get to 3 that would be great. And at that point I hope I will be able to do what I do today with my OpenID identity and use functions like CallVerifID when the transaction calls for that level of additional authentication.
So yes there is possibility - and now we just need to decide which we need to do first - get infrastructure available or get people educated as to what they can do today as a staring point.
Some things for thought .... I hope.
- Posted using BlogPress from my iPad
I have been thinking about that for a while. Especially in relation to the work that I have been doing on what effectively is credential re-use. She was correct in that most people do not know to look for the green bar in the browser indicating the extra diligence to validate the site. I think that it is a case of people not knowing why it is there and what it brings. But I also think the same is true of identity re-use. I think people do it today and do not realize it.
Now I do not mean just the re-use of drivers licenses, Social Security numbers and the such but of online identities. I started to think about my own environment. I use my Google identity to use many things today - the normal Gmail, Calendar etc but also using it to log onto other applications on my iPad, laptop and Android phone. I use my OpenID to access ToodleDo and other sites and many applications that I use leverage SAML, Oauth and OpenID to allow me to take advantage of credential re-use. Of course in a lot of these cases I also see Facebook and Twitter options for login so I have to imagine that people are using these rather than create yet another account.
I think the strength and advantage of NSTIC is the possibility that in a few years I will be able to do all my online functions using a small set of identities. I may always have that Yahoo mail address so getting rid of all but one is unlikely but if I can get to 3 that would be great. And at that point I hope I will be able to do what I do today with my OpenID identity and use functions like CallVerifID when the transaction calls for that level of additional authentication.
So yes there is possibility - and now we just need to decide which we need to do first - get infrastructure available or get people educated as to what they can do today as a staring point.
Some things for thought .... I hope.
- Posted using BlogPress from my iPad
Monday, November 1, 2010
Continuing the Thought
It has been a while since I started this thought but it is not a case that I felt it was a bad thought but more a case that I wanted to let it stew for a while.
In the past few weeks I have seen and heard lots of discussion in regards to attributes so I thought that this renewal of my thought process would be appropriate now.
The last point of discussion here was the thought that we do need to be able to share data to better identify the rights that someone has within an application or transaction. You will note that I use these words, "rights", "application" and "transaction" loosely and this is quite intentional as I believe the fundamental idea spreads across a broad spectrum of transactions.
When we talk about sharing of data, used to identify users, there needs to be agreement as to how we identify the data that is shared. In today's space this has been accomplished through broad agreement on data dictionaries. Sometimes this is based around specific industries while other times it is based nationally. One of the realizations that has come out of working in this area has been that these specific dictionaries can restrict the use of the technologies to a narrow band of the actual user community. While a financial sector has very specific needs to communicate within its sector it has become recognized that the same community has large interaction with other parties where their "standard" data dictionary is not necessarily understood.
Now it is easy in this case to say that maybe a global dictionary is needed or to rely on a national level dictionary that is driven by government standards or by existing best practices. The issue here has always been one of broad agreement and thereby practically implementable solutions. Generally speaking, the broader the agreement, the less practical it is in terms of it's use.
So let's think about how this has worked in other technical areas. DNS is a good example whereby translation is handled through a set of distributed capabilities. Could this idea also be used with a data dictionary service? Let's think of a "centralized" service that translates attribute schema elements between defined data dictionaries. There is no need to share actual data but a method to ensure that "name" is understood as one party communicates to another.
There are of course lots of specific implementation needs to surround this but I would first like to start the discussion to see if it is a needed model before we get to the specifics of things like, knowing who we are dealing with; protecting any sensitive transaction sets; and modeling an implementation to see what is needed from a management and operational perspective to ensure viability and usefulness.
Your thoughts on this are appreciated.
- Posted using BlogPress from my iPad
In the past few weeks I have seen and heard lots of discussion in regards to attributes so I thought that this renewal of my thought process would be appropriate now.
The last point of discussion here was the thought that we do need to be able to share data to better identify the rights that someone has within an application or transaction. You will note that I use these words, "rights", "application" and "transaction" loosely and this is quite intentional as I believe the fundamental idea spreads across a broad spectrum of transactions.
When we talk about sharing of data, used to identify users, there needs to be agreement as to how we identify the data that is shared. In today's space this has been accomplished through broad agreement on data dictionaries. Sometimes this is based around specific industries while other times it is based nationally. One of the realizations that has come out of working in this area has been that these specific dictionaries can restrict the use of the technologies to a narrow band of the actual user community. While a financial sector has very specific needs to communicate within its sector it has become recognized that the same community has large interaction with other parties where their "standard" data dictionary is not necessarily understood.
Now it is easy in this case to say that maybe a global dictionary is needed or to rely on a national level dictionary that is driven by government standards or by existing best practices. The issue here has always been one of broad agreement and thereby practically implementable solutions. Generally speaking, the broader the agreement, the less practical it is in terms of it's use.
So let's think about how this has worked in other technical areas. DNS is a good example whereby translation is handled through a set of distributed capabilities. Could this idea also be used with a data dictionary service? Let's think of a "centralized" service that translates attribute schema elements between defined data dictionaries. There is no need to share actual data but a method to ensure that "name" is understood as one party communicates to another.
There are of course lots of specific implementation needs to surround this but I would first like to start the discussion to see if it is a needed model before we get to the specifics of things like, knowing who we are dealing with; protecting any sensitive transaction sets; and modeling an implementation to see what is needed from a management and operational perspective to ensure viability and usefulness.
Your thoughts on this are appreciated.
- Posted using BlogPress from my iPad
Subscribe to:
Posts (Atom)