The project certainly has security implications, but I have another incentive to help out. All managers in my company are eligible for bonuses at the end of the fiscal year (which comes at the end of June), and these bonuses depend in part on meeting personal and departmental strategic objectives. One of my personal strategic objectives, for example, is to successfully deploy laptop encryption. If I don't do this by a certain date, I lose points that are used to calculate my bonus. And my peers lose points as well.
So we are motivated to help one another, and that's part of the reason why the project for automating account termination drew my attention.
Simply stated, we want to ensure that former employees can't gain access to any of our systems or the network. Doing so is a control objective tied to compliance with the Sarbanes-Oxley Act, but it's also a strategic objective of the company. Ultimately, we want the automated system to work so that when the human resources department marks an employee's PeopleSoft account as terminated, a series of activities will be triggered to automatically remove or disable that user's account from other user account repositories.
We use Microsoft Active Directory (AD) as our main directory infrastructure, and we have configured it so that users' accounts are automatically removed when they are marked as terminated in the PeopleSoft database. Those deletions mean that terminated employees no longer have access to Microsoft Exchange, file shares, SharePoint, our single sign-on infrastructure and several other applications.
The problem is that when a person is no longer allowed to access our systems, the process will have to include the automatic termination of RSA SecurID accounts. We currently use SecurID tokens to provide two-factor authentication to two main environments: our virtual private network and our extranet portal. Regular employees are authorized for VPN access, and portal access is extended to suppliers, partners and contractors. Using the portal across a Secure Sockets Layer VPN, these third parties get a controlled subset of access to our company's internal resources. Eventually, I plan to expand SecurID two-factor authentication for gaining access to our network gear (i.e., routers, switches and firewalls) and our Unix and Windows NT servers, and to integrate it into core applications, such as SAP and our upcoming product life-cycle management infrastructure. Shutting former employees out of the SecurID authentication server is a big part of keeping them out of company resources.
The RSA server's database can be synchronized with external Lightweight Directory Access Protocol (LDAP) directories such as AD. But currently, when we disable users from within AD, they aren't automatically removed from within the SecurID token database. Terminated users who have a token and the company's VPN client can gain access to our internal network. They may not have access to the Windows domain because their AD accounts have been terminated, but they are on the network nonetheless, and that's unacceptable from a security perspective. We have to configure our SecurID server to synchronize its user database with AD.
Syncing feeling
That task isn't trivial. If a mistake were made, we could completely wipe out or corrupt the SecurID database. Of course, we'll test this change in a lab environment and back up the existing database, but wiping out the database is still a scary thought. In addition, quite a bit of prep work has to be done. Because the synchronization process is tied to employees' usernames, we must ensure that the usernames within the SecurID database are identical to those in AD. Account reconciliation -- making sure that a single person isn't listed under different usernames -- takes time, especially with more than 5,000 users in the database. And when we find a user who has more than one username, we'll have to communicate our changes to the user in question.
The SecurID server offers a fair amount of flexibility in how we conduct the synchronization. We plan to run the synchronization so that regular employees will be automatically added to a SecurID group that grants them VPN access, while contractors, partners and other nonemployees will be added to a default group with no access. We'll be able to do this by configuring multiple LDAP synchronizations. Users properly registered in AD with a correct username will automatically gain access to the things they should gain access to. Partners, for example, will have SecurID access to the partner portal but not the VPN concentrator. And when the synchronization determines that a particular user no longer has an AD entry -- in other words, that the user is no longer an employee or some kind of partner -- then the user will automatically be deleted from within the Secur-ID server and his token will be placed back into the available token pool.
Once we extend the SecurID infrastructure to other areas, we will be able to conduct synchronizations to place, for example, network or Unix engineers in groups that give them SecurID access to the network or the server infrastructure.
If this project is executed properly, we will have an end-to-end process for automatically creating and terminating accounts. And that process will not only satisfy our Sarbanes-Oxley control needs and our corporate strategic objective, but also provide a more secure means of minimizing risks to the company.
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 mathias_thurman@yahoo.com, or join the discussions in our security blogs: computerworld.com/blogs/security
To find a complete archive of our Security Manager's Journals, go online to computerworld.com/secjournal.