Excessive Permissions

By: George Spafford

August 28, 2006

In March 2004 Roger Duronio, acting on his own, launched a logic bomb attack that crippled almost 2,000 hosts on the UBS Paine Webber network. The business impacts of this act were enormous and felt for quite some time as the organization sorted out the mess. UBS did a lot of things right and this article isn’t to diminish their work in any way. Instead, it help to illustrate why permissions need to be limited and risks associated with excessive spans of control taken into consideration.

Excessive permissions pertain to individuals have more rights on IT platforms than what is needed for them to achieve their business role. It goes to the old security maxim of denying all rights and only allowing what is needed. There are three common causes of excessive permissions.

First is that when the organization started and there was only a handful of IT people, or even just one person, the IT personnel had to perform many roles in order to perform their daily work and to back one another up. One person might have well performed development, network management and user support. As more people were hired their rights mirrored the people before them and as time went by everyone had a mix of authorities.

Second, some groups grant all of IT admin authority or given everyone high-level access as it seems to be easier to set an account up one time and then avoid the management required to deal with restricted authorities. The problem is that this mentality has a siren song of improved agility but incurs additional risks for the organization. In a given situation, one must ask, “Are the associated risks acceptable?”

Third, some organizations will have well thought out security policies but when incidents happen, additional permissions are granted to a person to resolve the situation at hand but, once the fire is fought, not removed afterwards. This “permission creep” is very common as organizations do not have the proper controls in place to ensure the rights are removed after the incident plus an additional control to routinely review accounts to ensure the associated permissions are valid.

In all cases, the rights certain individuals have are greater than what they should be for risks to be appropriately managed. As with UBS, there can be malicious activity conducted with the excessive rights. On a greater scale, there are also risks stemming from human error. When people having permissions greater than what their skills and knowledge can support, then a great deal of unintentional harm is possible.

Closely related to excessive permissions is segregation of duties (SOD) control. Essentially it is concerned with critical processes being under the undue influence of any given person or group. In other words, critical processes need to have tasks split across people and teams in order to have a proper check and balance system that ensures the validity of outcomes.

In accounting we know that it is a bad idea to have someone be able to print and sign checks because it would be very easy to write fraudulent checks. In IT we know there are areas where there are conflicts of interest so we prefer to not have users be security or system administrators, developers doing testing or developers with the ability to update production systems.

To properly address permissions taking SOD into account, organizations need to understand what IT services are critical and establish risks. From there, roles relative to tasks can be reviewed to see what combinations create a level of excessive permissions that puts process confidentiality, integrity and availability at an unacceptable level of risk.

Where security is compromised, either tasks need to be reallocated or compensating controls put in place to reduce risk to an acceptable level. When reviewing what changes are needed, it is important to bear in mind that there are often a lot of emotions attached to permissions so training and awareness activities will need to be undertaken to support the rganizational change.

In summary, excessive permissions put organizations at risk. Roles need to be periodically reviewed to ensure that the business is properly supported with segregation of duties taken into account and that system privileges need to mirror the defined roles. In this day and age, security is becoming increasingly important and permission models need to reduce risks to a level that management is comfortable with.

------

There are also risks with groups and system accounts having excessive rights. The point is that as the level of access increases, so do the risks to the organization should an account be compromised.