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.
To handle these ad hoc groups effectively, IT needs a way to cluster users, applications and devices into roles quickly and easily. Within that, IT must be able to support multiple roles per user and enable access policy that keys off the role information. Depending on Layer 2/3/4 LAN constructs, such as VLANs and ACLs or on server-based controls, is too complex and too rigid to support this quick pace of change.
To keep pace with the fast changes, IT should look for network devices that provide more intelligent control. Such devices can dynamically query identity stores for role information, apply access policies that encompass applications and devices, and have those policies follow the user. Only the user edge of the LAN sees all traffic, and only a centralized policy that encompasses users and their roles, applications and devices can meet the challenges of provisioning – and deprovisioning – these ad hoc groups.