Group Security Policies: Whose Right?

- Frank Cabri, vice president of marketing at Centrify Corporation (www.centrify.com), says:

Employees should get access based on their role and what they need to do. However, when an employee provides a cross category function, a database administrator needs to configure an underlying system (the employee’s membership in a group can be restricted to a given system for a given amount of time); and of course the auditing software is turned on and his actions are watched and recorded – most people do the right thing when they know they are being watched.

Any good security policy needs to account for inevitable exceptions, and the extent to which these exceptions can be handled appropriately within the guiding security framework is key.

Security Group Policies: The Right Approach

- David J. Lineman, president of Information Shield (www.informationshield.com), says:

Security group policies are the right approach, assuming a Microsoft-based network architecture that supports this approach for all employees. There are times when custom-built or legacy applications cannot be controlled using group policy, so it is a good idea to still have a higher-level set of management policies that work with the technical controls. The idea of limiting access based on the need-to-know is a high-level management policy that is supported be a variety of technologies.

It is critical to document what is actually done in group policies with written security policy documents. This enables the organization to document these security controls to auditors and third-parties with a need to evaluate the security posture of the organization.

Security Group Policies

- Manny Vellon, chief technology officer with Likewise Software (www.likewise.com), says:

Security groups are a great way to map “roles” into entities that can be enforced by the Operating System. Maintaining a group is a lot easier than maintaining explicit user lists in various different systems. Likewise uses AD security groups in various ways to control access to machines and also individual privileges via SUDO in Linux/UNIX.

It is important, however, to try to keep things simple. We have encountered many organizations that end up with more groups than employees.

Note, however, that your initial plan will never be right. If 50% of the users in the Finance department are requesting access to another computer, there’s probably a systemic reason for their need. If you can discover what it is (perhaps it’s all the folks in Accounts Receivable) then you can turn that into a business rule that gets automatically applied whenever new employee accounts are provisioned.

Likewise frequently encounters customers who deploy UNIX and Linux machines because they want better security then completely sabotage their efforts by employing poor security practices. Running standalone authentication and logging in with privileged (root) accounts is a recipe for disaster.