Managing integration and access privileges for ad hoc groups

In today's economy, companies are changing fast. If my company makes an acquisition, can I easily create a group of users to manage that integration, give them specific access privileges, and then dissolve that group when the transition has been complete?

This question raises a particularly interesting angle on the broad topic of the insider threat – what's a good way to provision access to sensitive information on a temporary basis. And regardless of whether your company makes an acquisition, all companies need a way to deal with ad hoc groups.

Ad hoc groups arise to support a number of activities, including M&A, joint development, key implementation projects such as CRM or ERP customization, and projects undertaken with partners. It seems every industry needs to support more of these groups, and do so more frequently.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

In today's economy, companies are changing fast. If my company makes an acquisition, can I easily create a group of users to manage that integration, give them specific access privileges, and then dissolve that group when the transition has been complete?

This question raises a particularly interesting angle on the broad topic of the insider threat – what's a good way to provision access to sensitive information on a temporary basis. And regardless of whether your company makes an acquisition, all companies need a way to deal with ad hoc groups.

Ad hoc groups arise to support a number of activities, including M&A, joint development, key implementation projects such as CRM or ERP customization, and projects undertaken with partners. It seems every industry needs to support more of these groups, and do so more frequently.

One of the most significant challenges is that these groups are nearly always cross-functional. Network and security professionals have spent the last 10 years automating and streamlining all the processes they could, but their efforts typically were focused within a given business group. With most M&A scenarios, as with ad hoc groups, you need to pull together people from different units, because their "day jobs" involve relevant expertise for the project.

But the day jobs don't go away. Most of the people in the ad hoc group are not permanently changing their role, but augmenting their responsibilities for this temporary project. As such, you need a way to assign privileges to people with multiple roles.

The temporary basis, the cross-functional dynamic, and the multiple roles all combine to make access control especially challenging given the rigid network infrastructures today. Most control mechanisms are static – virtual LANs (VLAN) and access control lists come to mind as the most common tools of the trade. But that infrastructure is not dynamic enough to keep pace with groups that come and go, nor can it accommodate the reality of people in multiple roles.

If you're going to separate users with VLANs and ACLs, a given user can be in only one VLAN, so how to put that critical order-entry person into the Oracle implementation project and keep his affiliation with the operations team?

Another approach IT to limiting access to resources for an ad hoc group is to build a folder system on a file server and dump resources there. However, these kinds of groups increasingly need controlled access not just to specific files but also to relevant applications and sometimes devices.

For instance, the partner-based project might benefit highly from Google applications for collaboration, but the organization may not want other people in the company to run these applications. Or perhaps the operations person on the RFID implementation team must access a bar code scanner to test that serial numbers are recording in the appropriate database field but the operations team as a whole should not be allowed to run those scanners.

In addition, these ad hoc groups will eventually dissipate, and people's access rights should be revoked at that point. The mechanism for deprovisioning a user must be as efficient as that for turning on the access in the first place.