The first step is to examine how the organization manages user access. Access can be defined in two states: predetermined access and real-time access. Predetermined access, also known as provisioning, is the process wherein access is requested, maintained and eventually removed. This access involves creating accounts for end users on the organization's networks, operating systems and applications to allow them admission to the information they need to perform their jobs. Real-time access is defined as the moment when a user actually logs into the account created for him or her.
Using RBAC access control to minimize provisioning time
For predetermined access, establishing an entitlement process using role-based access controls (RBAC) will provide large economies of scale for managing access. The idea behind RBAC is, instead of creating entitlements on a number of systems based on individual access requests, entitlements are grouped under a functional role or responsibility, and done so more consistently. For example, all employees in an organization might be entitled to email, Windows file share, intranet portal and benefits enrollment. Instead of creating processes for managing individual access by defining the roles of each employee, it is easier to grant an individual access privileges under that role.
RBAC roles can also be combined to reflect an individual's default access rights. For example, an enterprise security architect might have roles, including: architect, security, home office employee, benefits administrator, California resident, IT, etc. Each of these roles may have one or many account entitlements related to it, but at a glance, the security professional can ensure the person under question has the right accesses for his or her role in the organization.
As a demonstration, let's perform an informal user access review on the enterprise security architect and the roles in the above list. You should have flagged a bad access permission; normally an enterprise security architect wouldn't have "benefits administrator" permissions in his or her role, and these should be removed.
Managing a real-time data access policy
Real-time access can be harder to manage. While pre-determined access may be managed from a single console or interface, real-time access has many variables that must be considered. Is an account being accessed from inside or outside the domain? Is the right system being used to access information? How often is an account being accessed? When was the last time an account was accessed? Was there an issue with the access, i.e., too many login attempts before success? Was the device that was used to access the account supported by the organization (a question being asked more and more as users start bringing their own devices)? While this list doesn't include all the questions a security professional might ask, it demonstrates that verifying real-time access can be difficult.
When conducting a real-time access review, one easy way to pare down accounts is to see if there are any existing accounts that aren't used -- perhaps because the user was unaware of the account's existence, he or she never had a need to access the information, he/she is no longer with the organization, or the account was created in error. These orphaned accounts should, at minimum, be disabled and, in many cases, be removed with proper management approval. Similarly, determine when an account was last accessed. It's easy to run simple reports on inactivity to determine if there are accounts or services that are no longer being used; for instance a user might have been promoted and didn't inform the account management group that access to a certain system was no longer needed.
In this case, policies should be established regarding account inactivity for employees and others. An example policy might read as follows: "Accounts will be disabled after 90 days of inactivity for employees and 30 days for all others, including contractors, partners and customers." Finally, many systems highlight failed or multiple login attempts. Accounts flagged by these logs should be a priority for examination of attack or misuse.
Security professionals should also be aware that they aren't the only ones involved with access review and should leverage help within other parts of the organization. For example, the network team may also play a role in access. Today's perimeter control devices can now determine more about a user attempting to access information inside or outside of the organization's boundary than just his or her IP address. In many cases, perimeter tools can monitor, identify and block, if necessary, unauthorized device types, access from unfriendly countries, viruses and spam, and, when tied into the identity data repositories, even specific users on the device. Intrusion detection and prevention systems (IDSes/IDPes) are becoming commonplace in many organizations' intranets, and the information provided by their management tools can be invaluable for monitoring and examining access.
While many organizations may not be fully staffed, roles can potentially help consolidate thousands of entitlements into a more manageable number of access objects to ensure the correct accesses are created from the start, thereby minimizing the time required to look at every account request. For those accounts already created, by putting policies in place for disabling or deleting accounts that are inactive, you'll be able to clean up the access environment. Finally, while you may not have a security colleague with whom to engage in these activities, by reaching out to other departments within the organization and utilizing their management tools, access can still be controlled and managed collaboratively and without overburdening you and (whoever remains on) the security team.
About the author:
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company who has worked in the security industry for more than 20 years. He specializes in security/identity management strategies, methodologies and architectures.
This was first published in May 2010