What Does WordPress Security Have In Common With Soylent Green?

Soylent Green Is What?

Let me pose a question. What does Soylent Green have in common with the greatest security flaw of WordPress?

From a security perspective, the most recent versions of WordPress are much improved. But WordPress continues to have one great weakness that has nothing to do with the code under the hood.

The greatest security flaw that WordPress will always have is … people.

What Is Security?

Security can mean different things to different people in different contexts. Typically, security threats can be broken down into two major groupings; external threats from outside the organization and internal threats from inside the organization.

It’s the internal threats that have piqued my interest lately. But more specifically internal threats that are non malicious.

A non malicious internal threat is any activity that is not performed explicitly to cause harm to the business. In other words, accidents.

I Deleted You. Woopsies.

A few weeks ago, a client called me in a panic because all of their WordPress accounts had been deleted. I tried to log in and had no luck. As it turns out, my account was deleted as well.

So what happened?

We discovered that a legitimate user within the organization, who did not know WordPress, was granted an account with administrative privilege. That person logged in, took a look around and wondered why there were other accounts “in her account”. Apparently, she thought that the instance of WordPress was hers alone and that each user had their own instance. So she set about “cleaning things up.” She deleted all accounts and when prompted, converted any assets to her name. In the end she had what she considered a perfectly “cleaned up” WordPress environment.

Of course that’s not how WordPress works so this presented a problematic situation for all involved.

How Did It Get To This Point?

The way I see it, there are two problems in the above scenario. First, the user was not given the proper training. In this case, the WordPress ecosystem is self-managed by my client and they have a designated individual responsible for training. But the user who deleted all of the accounts never received training.

Which brings us to the second and probably more important problem.

The new user was given an administrative account instead of a lower level account. This resulted in an untrained user effectively having the power to do a great deal of damage.

WordPress, like any other CMS, features a tiered account management system. Different users can be assigned different levels of access, each of which has different privileges and restrictions.

The administrator level has all privileges, and no restrictions. It is both the most powerful account and the most dangerous.

This user should never have been given an administrative account and certainly not before any training.

At my client’s request, I recovered the WordPress site from a backup and found that all active accounts were set up as administrator accounts. Yet only one user required that level of access.

This scenario is the very definition of a recipe for disaster.

A Better Way

So what is a better way? I provided my client with some suggestions that I will republish here for any organizations facing the same issues.

Who should have access?

This is the first question to ask. In the backup, I found about 15 accounts. Only about half of those accounts had any reason to do any type of content management. Of the remaining accounts some only had accounts in order to make a single edit and were never expected to access the system again.

The only people who should have access to your WordPress system are the people who need to actively edit content on an ongoing basis.

Training is a must.

No one should ever access an organization’s WordPress installation without proper training. A great deal of damage can be done by someone just “clicking around.”

Sometimes organizations have individuals who are competent in the use of WordPress, but not competent in the training of WordPress. That’s why companies like mine exist. To take that burden off of you.

It may sound like I am pitching you, but the fact is, WordPress changes all the time and you can’t take time away from your day to day tasks to keep up with all of those changes.

Decide on access levels.

Not everyone should be an admin. In fact, the best WordPress environments only have one admin. That means that there is only one point of contact for total destruction. It sounds apocalyptic, but any admin level account can literally wipe out your WordPress site.

WordPress features several levels of access. Each user should be thoughtfully placed in one of those levels in accordance with their intended function.

Define functions.

Who is responsible for what? I see a lot of organizations that have a whole team of people managing a site, but none know where their responsibilities begin and end.

Making decisions on who is responsible for what will make for a more streamlined and organized process. And even better; it will be more trouble free.

Don’t make everyone an admin.

This is the lazy way out. And when I say lazy, I mean really lazy. It takes the exact same effort to create an admin level account as any other type of account. I often hear someone say that having all accounts with admin privileges means that everyone can work equally and without restriction.

Sounds great, but given that different people have different roles, not to mention different levels of understanding and proficiencies, is it really the best thing to give everyone equal access to potentially destructive features?

Audit. Audit. Audit.

Businesses usually audit their books once a year in order to make calls on improving the business. The same applies to WordPress. If you have accounts that are bound to people who have been fired or no longer use the system or have been moved to other positions in the company, delete their accounts.

The same goes for changing access levels. If the person who was the admin only needs access to content, perhaps they should have the access level changed to an editor.

The point is, it’s in the best interest of the business to review all accounts periodically to make sure that the WordPress ecosystem is functioning as efficiently as possible.

Deactivate.

Deleting accounts is a good idea, but sometimes, there is a lot of content associated with a particular account and deleting that account may eliminate some historical benefit. In that case, accounts can be deactivated. The account still exists and all content related to that account is intact, but that user can no longer access the system in any way.

It’s a great compromise.

Named accounts.

One of my greatest pet peeves with users of WordPress is when an organization creates a generic account and then passes the credentials for that account from person to person.

A better approach is to give each individual their own named account. This affords you the ability to disable or delete accounts without having to worry about who else will be affected and also gives you a historical reference should something go wrong.

Under no circumstances should multiple people share the same WordPress account.

Soylent Green Is People!

So while this article is far from comprehensive, it does illustrate that no matter how WordPress improves from a security perspective, it’s always the Soylent Green, um, I mean, the people who will present the greatest security challenge.

How do you handle giving accounts to the Soylent Green in your organization? Let me know in the comments. And if you need help setting up your WordPress accounts or choosing roles, get in touch and I can help you set parameters in your organization.