Pentagon adopts Smartcards - a discussion in technology limitations
Hmm - was reading this story today on eWeek - its about the Pentagon adopting the use of smartcards for system logons, building access and potential payment of services.
Im not that impressed - at Microsoft we have been doing that for years! We use our smartcards as Photo ID's, to access buildings on campus, logon through VPN (its mandated!) and interactively on PC's and Terminal Servers. We can even use our smartcards as a cash card and pay for meals at the cafeteria. We even automate the rollout of them with self (certificate) enrollment which seems to be better than what the Pentagon is doing :) Active Directory has this support all built in! Wow you say - they are the answer to everything!...but there’s significant limitations...smartcards at present can't be used for everything!
As I’m reading it triggered some thoughts - what about the applications that aren’t pluggable with an alternative authentication provider? What if identity is hard coded into database tables like lots of applications are today? Are they doing anything else to provision and de-provision users?
Then I read on and see that they are going to use a "Single Sign On" product. Oh no...Here we go...now many of you know my thoughts on SSO. At the moment its way overpromised and because of much media attention, customers tend to go for that because they think it’s achievable for everything. In many cases true SSO is simply not achievable because the applications themselves cannot support anything but a username and password!
So then I look at the product demo - and no surprise here - they achieve "SSO" by screen scraping the logon form, securely storing your credentials elsewhere and then replaying them next time. It probably addresses the user problem of remembering the password and thus has an impact on password resets - but what about if the password needs to be changed? The user has likely forgotten it by then and is now needs it to be reset anyway by the helpdesk so they can then change it? Then they have to reenter the new password so the SSO provider can remember it for them? Hmm...thats messy every time it changes...
Lets go back then to the Pentagon example and they want to put in place a strong assertion of your identity via a Smartcard....They essentially plan to map a strong two factor smartcard credential through to the weaker username and password combination through a managed SSO provider that aims to capture the credentials on the form and replay them next time you access that service. Don’t get me wrong - these SSO tools are useful and help solve user pain but don’t really solve major cost issues and definitely not security ones - at the Pentagon they probably are doing automated lifecycle management to complement it but it’s not mentioned.
Let’s ask some basic questions:
- Have they truly achieved SSO here with Smartcards? No - there’s no federation of identity and not all the applications can support token based authentication...and who can really criticize?...it’s simply not technically possible with many apps without major rework.
- Have they improved security? Somewhat but not in everything as we can see - the usernames and passwords are still very much there in the applications so unless lifecycle management and security policy is employed they may still have a serious problem.
- What about cost reductions? Not directly. Why? Because rolling out smartcards and implementing this form of SSO doesn’t really do anything about the number one costs to an Business's IT shop - provisioning, de-provisioning and the whole lifecycle of managing identities and passwords in a connected business process.
Here’s what I recommend - a recipe for a successful identity project that saves money, improves security, allows for compliance reporting and delivers value to users.
To help explain this the first goal you must have in mind is to reduce the number of directories you have if possible and once youve done that then the goal is to aggregate and join the identity information so that users have one logon and password if possible. Theres going to be some applications that have no hope but getting the majority of them will reduce a lot of costs.
1. Take a look at how many applications you actually have that have identity embedded in them - we're going to be looking for opportunities to consolidate application directories
2. Of those applications find out if they can either federate identity (trust another authentication source via tickets or tokens) or support direct authentication into a single authentication database like Active Directory for example. SAP R/3 is an ERP application that can support a trusted authentication from an Active Directory account, via a Kerberos ticket and mapped to a credential in SAP. Performing this exercise will allow you to consolidate directory services and make steps 5 and onwards easier.
3. With the web applications - take a look if they support federated authentication via something like WS-Federation (Microsoft implements its as ADFS in Windows Server 2003 R2) - many don’t but its worth checking.
4. Find out if it’s possible for minor rework with any of these applications to authenticate directly - highly unlikely to happen but again worth checking with the vendor or developer that did it.
5. If you cant do any of these above options, youre now totally limited to making sure that you reduce the number of accounts that people actually use and duplicating each identity in each system that the user needs access to. What’s important here to note is that you must also embark on security compliance process otherwise you could open yourself to other problems - more to come.
6. Start looking at the business process of how the identity lifecycle works, the hire/change/retire process - in your organization it could be that new employees are hired officially through HR and entered into the HR system first. As they change or need access to new systems, IT gets involved along with access approvals from higher managers. As employees retire - HR deletes them. So instead of allowing this to be totally manual like it is today and disconnected - let’s automate it and save money.
7. Audit your current security policies – if you have weak passwords now or don’t do security enforcement of password complexity/history then you potentially spread that weakness to other systems – if I can easily brute force a password on one system – then I can use than on another system too because it’s the same.
8. Evaluate tools that can help automate the business process. MIIS is one that I’ve talked a lot about before. It will help to provision users into systems, add them to the right groups (no more and no less), and centrally reset passwords so that users have one username and one password. Heres the recent webcast of the security seminar where I spoke on it...
9. Combine it with a workflow tool to help manage approvals. If users need additional access then this should be part of a workflow that manage requests for access to group/system owners with a business reason for access and then upon approval the user is automatically provisioned with the correct level of access. This can additionally be reported on for SOX and security compliance.
10. Implement a Self Service Password Management tool for the users to reset their own passwords…I demo’d this at our recent Security Summit– we will be coming out with one shortly as part of MIIS Service Pack 2.
Beginning on a journey such as what I’ve talked about will really help your business reduce costs and do all the things I said at the start. Pursuing the pipedream of SSO first up in your organization is fruitless in reducing costs and really addressing the problem until you have looked at doing these 10 steps.
So in conclusion - Yes Smartcards do improve security and yes these SSO solutions do help make it easier for the users but only in complement with a good identity plan such as the above.
Comments
- Anonymous
April 12, 2006
Hi michael
Enjoyed reading the post, I am implementing an IDM product so I really understand were your thoughts on identity are coming from.
I have a question for you about the sap application .
As an application that support authentication via a Kerberos ticket, is it possible for that application to do authorizing based on AD??
For example I will map some AD groups to responsibilities on the sap and by changing the groups in AD I will be able to change my permission in the SAP application?
Yours
zhai - Anonymous
April 12, 2006
The comment has been removed - Anonymous
April 24, 2006
A fantastic article Mike, I am really interested in Identity management and your article gave me a lot to think about.