Identity management in an IT world that mixes the cloud, legacy mainframes, and everything in between has become very challenging. 21st century businesses have knowledge-workers spread across diverse geographic locations using a broad array of devices and methods of connectivity. There was a time when the only security necessary was a keypad on the computer room door. If you created your JCL (Job Control Language) deck correctly you had the ability to access any and all resources available to the mainframe. Program results were spit out onto green-bar, which could then be analyzed and acted upon by business users.
Modern Times
Fast forward to today. That same mainframe may be spitting out the results of those original batch files, but now the output is bits and those bits are dumped into a database where that data can be analyzed, sliced, diced, reported on, and acted on by a plethora of applications. Those applications were probably developed at different times using different technologies. If you are like most organizations you have evolved through various computing methods and different ways of authenticating and authorizing users.
For most of us the history of authorization probably went something like this. In the (computing) dark ages access to a particular application was controlled within that application. Once we began to establish local networks, the network protocol established identity by forcing users to log-on to the network. Once established, that might have been sufficient to allow users to authenticate to new applications but that probably didn't work for those existing applications with their own user management store. Next we moved to networks built on the Internet Protocol (IP) which used various flavors of the Lightweight Directory Access Protocol (LDAP). Users now had a new network log-on which almost certainly was not integrated with any existing applications.
Most organizations worked around this issue by creating custom single sign-on applications that provide a cookie or token that traveled from application to application with the user. If you combine that with some sort of password synchronization across the various authentication schemes and a look-up table that lists individual user's authorization you have a kludgy homegrown single sign-on system that probably works pretty well. At least until you need to move to something like Active Directory. Then you need to reconcile a user's AD account with all those other accounts and authorizations you have been building over the past 40 years.
The Outside World
This all would be moot if our computing world was contained within the walls of our corporate firewall. If you have complete control over your environment you can do just about anything you want to control access. Unfortunately that is rarely the case. Our users are not only dispersed but they use a wide range of devices. Often the only commonality that we can assume for client (user) machines is that they access corporate resources using HTTP(S) over TCP/IP.
There are initiatives in many organizations to provide a computing experience that can be largely (although not entirely) device independent. And that brings us to a new paradigm…we need to provide what is essentially Web SSO. I need to be able to support large numbers of users accessing corporate resources using a Web browser–and that browser may be Safari, Android Browser, Internet Explorer, Firefox, Opera, Google Chrome, etc. The devices range from Blackberry's to iPhones and iPads to corporate laptops with disk encryption. Is it reasonable for a remote user to expect that they should be able to perform useful work using an atypical device while they are flying from the east coast headquarters to the San Francisco office? It is reasonable if that user is an executive vice president.
These are not hypothetical scenarios. These are real world issues that we need to resolve before they become uncontrollable and ultimately unmanageable. We, as providers of information throughout the enterprise are caught in the complex web of balancing the need for actionable information with the need to protect that information. That balance is also dependent on two other factors–one tangible and one intangible.
Given enough money we could provide every knowledge worker with a device of their choosing with custom biometric and token-based authentication providers. These devices could connect over any available network using PGP type encryption with all local information also encrypted using triple DES. Authenticated users would be permitted access to whatever computing resources they are entitled to, using a claims-based system that has been retrofitted to all legacy applications. That sounds fairly secure. It also sounds fairly expensive. And impractical.
The bottom line matters. IT provides services to the revenue producing parts of the business. Unless IT can demonstrate a positive ROI the business isn't going to invest in new technology. Security is not easily quantifiable, but we know the problem with IT security is it's only as strong as its weakest link. Biometric authentication for devices does little or nothing to bolster security for the weak links and the weakest link invariably is social.
Case in Point
Last year I noticed I wasn't receiving statements or mailings from a particular organization (which will remain nameless). I attempted to log onto the online account site and was denied access. I then e-mailed customer service. Armed with nothing more than the account number and my name I questioned why I wasn't able to access that account. I was told that the registration for that account had been changed some months ago. I asked the representative to reset the password, the e-mail account, and the mailing address. No problem, Mr. Rolich we deeply regret that someone has been using your account. All it took was three e-mail messages. No wonder my account was hijacked in the first place! Now this was an extreme case but it's true. Customer services representatives want to help provide good customer service. The representative in this case reacted to my outraged e-mail by "restoring" my credentials without causing me to jump through a bunch of hoops. Was that good customer service? Absolutely not–that particular organization does not have the slightest concept of what it means to protect customer privacy.
The Real World
So how do we find that sweet spot balancing secure data and providing access to data? We need to look at the problem from a macro perspective–not just from an IT security perspective. In short we need to look at corporate governance. There are types of data that can never be exposed outside the firewall. Payment Card Industry (PCI) information which includes personal user information, account numbers, PINs, etc. must be protected at all costs. Proprietary formulas and operating standards, certain financial statements, and merger and acquisition data are examples of other data we would normally classify as highly restricted. This is data that is so essential to the operation of the enterprise that compromising it could cause serious financial consequences or loss of market share. This stuff never leaves the walls of the enterprise.
There is another substantial body of information that is necessary to manage the business and which we do not want to fall into the hands of competitors or adversaries. This information may be called confidential–compromising it would be serious but wouldn't threaten the value of the business. Corporate governance can and should dictate the special handling for this data that balances the need to use this information while keeping it reasonably secure. IT can provide methods to supply security but it is not IT an function to dictate the depth of that security.
E-mail and Security
That confidential data is being distributed throughout the enterprise now. E-mail is the most likely means of transmission. An executive tells her admin to send the quarterly financials for the region so she can study them on her flight or in the hotel. If corporate policy forbids sending more than a few kilobytes of attachments to an e-mail the financials might be placed on a thumb drive or perhaps even a third-party file-sharing application like Dropbox. Now we're starting to lose control. Since we have not provided a reasonably secure method of accessing business critical data, users are finding unsecure methods of sharing information. By the way, I like and use Dropbox, just not for sensitive data that isn't mine.
Get With the Program?
In my experience ease of access to corporate information always wins out over electronic security best practices when the user is a senior executive. That's why it is so critical for IT to provide reasonably secure methods of data access that also ensures a certain amount of accountability. And let's not forget about device agnosticism. I'm an ardent advocate of multi-factor authentication, but my suggestions have been vetoed too many times for me not to accept the inevitable. There will be situations when you will need to provide confidential information in a way that is barely secure. And when that happens all you can do is make a best practice recommendation based on the business requirements presented to you.
Get Real
A typical need is something like this. Regional VP's are generally not sitting at their desk at corporate headquarters. They are traveling somewhere in their region managing their direct reports. In order to assess the performance in their region they require immediate and easy access to financial and performance data. Being VP's, they are used to doing things in a certain way–and that way does not involve booting up a corporate laptop, connecting to an unfamiliar Wi-Fi network, and then accessing the corporate network using an RSA device and a PIN in addition to their username and password. The preference this month is to use a tablet-like device that will easily connect to a wireless network and which already has pre-configured links (configured by their admin) that provides them access to this morning's financials. That's it…those are your requirements. You can either satisfy those requirements or go do something else.
So after being righteously indignant about the lack of security you meet those requirements in a way that still provides a modicum of protection. You ensure that the device itself has its own required login. In a demented sort of way you could actually call that the first part of a two-factor authentication. You ensure that data actually stored on the device is encrypted. You ensure that data is accessed only over SSL. You ensure that the organization enforces a strong password policy. And that's about all you can do on the user (client) side. On the server side you ensure that you are logging all access by username, device ID (MAC address), IP address, as well as date, time, etc. You also might want to consider enforcing IRM (Information Rights Management) so that you can control the life cycle of the documents. This is not a strong security solution yet it is one that provides enough security to be reasonably confident that corporate data is being protected. If nothing else it provides a heck of a lot more security than Dropbox. Welcome to the cloud.
Please address comments, complaints, and suggestions to the author at prolich@yahoo.com.
© Touchpoint Markets, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.