Managing integration and access privileges for ad hoc groups
Insider Threat
By Jeff Prince, Chairman and CTO of ConSentry
,
Network World
, 05/11/2009
- Share/Email
- Tweet This
- Print
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.
Comment