The Dangers of Excessive Permissions

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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 impact 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’s intended to illustrate why permissions need to be limited, and the risks associated with excessive spans of control need to be carefully considered.

Individuals are said to have “excessive permissions” when they have more rights on IT platforms than what is needed for them to achieve their business role. 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 if an account is compromised.

The need to avoid excessive permissions calls to mind the old security maxim about denying all rights and only allowing what is needed – a practice that can save untold time and money.

Three Scenarios to Avoid

There are three common scenarios in which excessive permissions are granted.

The first occurs when an organization is founded and there are only a handful of IT people, or even just one person. This small staff has to perform many roles in order to keep up with their daily work and to back one another up. One person might handle all of development, network management and user support. As more people are hired their rights mirror the people before them, and as time goes by everyone has a mix of authorities.

Second, some companies grant all of IT admin authority or give everyone high-level access, as it seems to be easier to set up an account 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 this situation, one must ask, “Are the associated risks acceptable?”

Third, some organizations have well thought out security policies, but when incidents happen, additional permissions are granted to a person to resolve the situation – but once the fire is out, access is not disabled afterward. This “permission creep” is very common since some organizations don’t have the proper controls in place to ensure that rights are later removed. Also needed: An additional control to routinely review accounts, to ensure that the associated permissions are valid.

In all these cases, the rights that certain individuals have are greater than what they should be for risks to be managed appropriately. As with UBS, excessive rights can lead to malicious activity.

On a greater scale, there are also risks stemming from human error. When people are allowed permissions greater than what their skills and knowledge can support, a great deal of unintentional harm is possible.

Next Page: Happiness is a Double-Signed Check

Happiness is a Double-Signed Check

Closely related to excessive permissions is segregation of duties (SOD) control. Essentially, SOD guards against critical processes being under the undue influence of any given person or group. In other words, the tasks involved with critical processes need be split across people and teams in order to maintain checks and balance to ensure the validity of outcomes.

In accounting we know that it’s a bad idea to allow one individual the authority to print and sign checks – it’s too eay to write fraudulent checks. In IT we know there are areas where there are equivalent conflicts of interest. We prefer to not allow users to be security or system administrators, developers to do testing, or developers have the ability to update production systems.

To properly address permissions using SOD, organizations need to understand what IT services are critical, and establish reasonable risk levels. From there, roles relative to tasks can be reviewed to see what combinations create a level of excessive permissions.

Avoid any permissions that put process confidentiality, integrity, and availability at an unacceptable level of risk. Where security is compromised, tasks need to be reallocated or compensating controls put in place to reduce risk to an acceptable level.

And remember one key fact about employees’ egos: When reviewing necessary changes, bear in mind that there are often a lot of emotions attached to permissions. So training and awareness activities will be needed to support the organizational change.

Clearly, excessive permissions put organizations at risk. Roles need to be periodically reviewed to ensure that the business is properly supported with segregation of duties; 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.