As I've mentioned in previous columns, my company has invested in RSA SecurID to provide two-factor authentication for access to our critical infrastructure, namely routers, switches, firewalls and production Unix servers. As you might recall, two-factor authentication entails something you have (like a bank ATM card) and something you know (your PIN).
On our network, the SecurID token (something you have) displays a random number, or "tokencode," which changes every 60 seconds. That, combined with a user-defined PIN (something you know), represents what is termed a "passcode."
To date, we have deployed about 150 tokens to mostly network engineers, systems administrators and information security personnel. They are fairly savvy individuals, so deployment, support and administration have been pretty straightforward.
Soon, though, we will begin to spread two-factor authentication to other areas of the company. Any employee who needs to remotely access the network via our Cisco VPN will need a SecurID token to authenticate to the network. SecurID tokens will also be required to associate to one of our corporate wireless access points. They'll be needed when off-site users check their e-mail via Microsoft Outlook Web Access. And the list goes on.
Eventually, every employee will have a SecurID token. Once that happens, it will be fairly easy to SecurID-enable applications and other areas of the enterprise, because no matter what a user is attempting to access, the use of the token remains the same.
For now, we're focusing on more than 5,000 employees, but deploying tokens to that many users and then supporting them calls for proper planning. A dedicated project manager is coordinating the various steps in this project, the first of which involves communication and training. We want end users to feel familiar with SecurID tokens before they actually receive one. The training and communication process will include mass e-mailings, a Web site with an FAQ and PowerPoint slides. Some of these materials have been developed by my infosec group, and others are being provided by RSA Security Inc.
The next step will be distribution. Those 5,000 employees are located in almost every state and major city in the U.S., plus India, Singapore, China, Mexico and Europe. To handle this logistical nightmare, we're splitting the token recipients into three groups.
The largest of these groups by far is made up of employees who need SecurID tokens. We decided that the most efficient method of providing them is to have a consultant send tokens to geographically identified contacts, who will then deliver tokens to individual users. The consultants will be able to focus entirely on the token deployment and not be distracted by other duties.
The second group consists of new employees. With them, the easiest thing to do is to work with the security badge office. Each new hire, even those who will work in home offices, is required to have a security badge. All we have to do is modify the new-user provisioning process to flag those who will need a token.
The third group is made up of existing employees whom we haven't identified as needing tokens but who suddenly require one. Those users will be asked to contact the help desk to obtain authorization. After that, the security badge office will send out the token.
Once an employee has his token, he must initialize it using an RSA SecurID Web-based application called Deployment Manager. Each user will visit a Web page, where he will answer a series of questions in order to be authenticated, enter the serial number on his token and then set up a PIN. Deployment Manager runs on an Apache Web server and will talk to a back-end Oracle database server, so our database administrators are involved in the overall project plan. They're creating the database so that we can test functionality prior to production.
The help desk will play an integral part in supporting the SecurID deployment. Inevitably, some users will forget their PINs, lose their tokens or cause the tokens to be out of sync. The help desk will address the most common issues with another Web-based application from RSA Security, called Quick Admin. We already use this application to support our initial 150 savvy users, but we'll have to provide the appropriate amount of training to the help desk staffers so they can attend to the brunt of support calls. The infosec group will handle anything outside of what the Quick Admin tool provides.
On the hardware front, a primary authentication server and two replicas are currently handling all the SecurID token transactions. The primary RSA ACE/Server contains the database of authorized users, including the permitted relationships between individual users and protected devices. The primary database is frequently synchronized with the replicas, and the load is automatically balanced, providing for a pretty decent fail-over configuration. If the primary or either replica should fail, the other servers can handle authentication requests.
Although our current deployment model could probably handle the increase in authentication requests as we scale from 150 users to more than 5,000, we plan to upgrade the servers and increase the number of replicas, some of which will be placed in key overseas locations.
All in all, and with the project manager's help, we have a robust, comprehensive plan, and I expect that when we finally pull the trigger, we'll have a smooth deployment and an aggressive support model to address user needs.
What Do You Think?
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org, or join the discussion in our forum: QuickLink a1590
To find a complete archive of our Security Manager's Journals, go to computerworld.com/secjournal.