Content Management Threat Report:

povertywhyInternet and Web Development

Nov 18, 2013 (3 years and 8 months ago)

81 views

1







Content Management Threat Report:

WordPress

Katie Dobruse, Dean Holden, and Minh
-
Tam Nguyen

April 20, 2012



2

F
AILURE TO LAUNCH

As an organization grows, it may cho
o
se to adopt a new content management system
to suit its changing needs. Successfully navigating such a transition requires
considerable organizational effort, as there are many ways for the adoption of a new
system to wind up dead in the water. To avoid th
is fate, an organization

V
ARIANT
1:

R
ESISTANCE TO ADOPTIO
N

Insufficient buy
-
in from key stakeholders (ex. upper
-
management or key mid
-
level
managers) to
roll out

a new CMS.

Causes

Certain stakeholders may make the decision to adopt a new CMS, but other
stakeholders may not put their support behin
d the effort. Workers below the

latter may
therefore not take steps necessary to make
CMS
adoption possible.


Pre
-
conditions

This may happen i
f the CMS was chosen because a particularly persuasive consultant
mana
ged to convince the CEO of
its

“sexiness,


rather than because the CMS met the
organization’s needs in terms of usability, scalability, and sustainability.

I
f there is a l
ack
of communication
and
transparency

on the part of management to explain why the
ch
angeover is occurring, employees might drag their feet.

Problem

Without the top
-
down implementation of an organization
-
wide adoption

plan or training
system
, apathy and passive aggression may derail the
process.

E
xample

Without pressure from above to have
all employees train on and begin using
WordPress, people may not make the change over.

If no one knows how to start
running WordPress, much less
when

they’re expected to do so, it’s not going to happen.

C
onsequence

Consequently, there would be
organizational fragmentation, with members not using the
same system (or at least not using their shared system to its fullest capabilities).


R
eferences

K
evinjohngallagher.com
: “
T
he Butterfly Effect


S
uggested

readings

The WordPress Codex



3

V
ARIANT
2:

E
NTRY BARRIERS

While WordPress may be an accessible blogging platform, using it as a CMS is more
challenging. Customizing it as a CMS requi
res a minimum level of technical proficiency
which not all member of an organization may possess. (Yet the goal of using
WordPress would be to have a system that did
not

require hiring outside professionals
to create, maintain, and update the CMS.) The Wor
dPress interface is non
-
intuitive (for
anything beyond posting a blog post, anyway)
,

which plays into its high learning curve.

Causes

WordPress’s interface isn’t truly WYSIWYG in the sense that many non
-
expert users
expect. You can’t simply drag and drop;
some training is required to use WordPress to
its full capacity as a CMS
.

Pre
-
conditions

Some (dare I suggest, older?)
employees
may

lack in existing tech skills and have
difficulty acquiring new ones
.
H
igh employee turnover

may also be a factor
.

Problem

T
hose employees who lack the
ability

to quickly adopt new digital literacies will take a
long time to adopt the new
CMS
, if they ever manage to. They may be unable to learn
the new system, and may therefore be unable to perform their regular duties as well
as
they did with the previous system.


Program suites like MS Office and the Adobe Creative Suites vary primarily by version
and OS, but the very customizability of WordPress’s interface that makes it so
potentially powerful means that

every time a new
employee is hired, he or she will have
a prolonged period of less
-
than
-
optimal productivity while learning the new system.


E
xample

If the organization is running a highly customized version of WordPress, even previous
experience with WordPress does not gu
arantee that an employee will hit the ground
running. I
f

and when

this

employee

leaves the organization, the cycle of learning will
have to be repeated.

C
onsequence

The organization will have to sink time and energy into training both existing and new
employees, and doing so may not even be a long
-
term investment.

R
eferences

K
evinjohngallagher.com
:

Making things up, entirely



S
uggested

readings

W3.org/History: “
Information Management: A Proposal
.”



4

V
ARIANT
3:

N
OT A ONE
-
SIZE
-
FITS
-
ALL
CMS


WordPress

wasn’t built to be a CMS
, and it certainly doesn’t function as one out
-
of
-
the
-
box
.

There are functions that WordPress does not do well that many organizations
might wish to use (ex. event calendars, ecommerce, etc.) that the organization might
only discover as they attempt to adopt the new system.

Causes

WordPress simply isn’t meant to

be run across many machines with many different
OSs.
It’s not well
-
tested enough across different browsers (and versions) and operating
systems to meet the needs of large corporations

Pre
-
conditions

The decision to adopt WordPress must have been made with
out asking what the
organization’s requirements for the system would be. (Shocking

I know

but not
unheard of.)
The o
rganization must be using WordPress to do more than blog.

All
employees must be expected to use the CMS, not just those in IT.

Problem

Makin
g WordPress go beyond its blogging roots to effectively function as a content
management system r
equires a customized back
-
end to
grant the necessary range of

functionality, which may require skills that no current employee has.


Assuming that someone with
in the organization does possess these skills (or that the
organization is willing to hire a freelancer to construct the interface),
WordPress does
not easily support the number of editors that many organizations would require.

There
may be difficulty in d
etermining who has what level of access, in order for e
mployees to
perform their tasks. A balance must be struck between allowing employees the authority
to perform their regular duties without constantly needing an admin’s approval, and

granting the techn
ologically
-
inept the power to accidentally crash the system.


E
xample

WordPress make
s

it difficult to manage a large number of pages (say, beyond 20)
,

because there’s only one way to view pages. Without the ability to efficiently sort page
content, building an online catalogue would be a nightmare.

C
onsequence

If the organization planned on becoming the next Amazon.com, disappointment would
inevitably
result.

R
eferences

K
evinjohngallagher.com
: “
WordPress has left the building
.”

Stackoverflow.com/
Q
uestions: “
Is WordPress good for buil
d
ing a large CMS site with
many pages?


WPtavern.com: “
Some
organizations and WordPress just don’t mix
.”

5

S
uggested

readings

One
e
xtra
p
ixel.com: “
The autopsy of WordPress
as CMS with 25 great WP pl
ugins
.”

S
TRATEGY

Develop an implementation strategy

Prior to adopting
WordPress
, conduct a survey of the
organization’s
tech level and
employee tech skill level.

Determine if hardware or
software updates are needed to
enable

individuals or departments
to
operate the organization’s version of WordPress
.
Also, f
ind out what level of technical assistance will be required to

get everyone in the
organization to
transition successfully. If it is clear that the CMS transition
is

feasible,
d
ecide what you’re going

to do and when, and then get everyone to commit
to it. Hold
people accountable
for completing milestones by set deadlines, with clear
consequences for failure to meet them
.

T
actics

1.

Conduct “Getting to Know WordPress” workshops of different levels, from a
very
basic handholding level for the least digitally competent, to a more advanced
overview for users who are digitally literate enough that they only need an
introduction to get going.

2.

Collect online tutorials for completing common workflow tasks (or, if
the
WordPress interface has been customized considerably, h
ave someone create a
series of screencast videos specific to that interface
). Make
these materials

both
visible and accessible so that if employee
s

get stuck during daily task
s
, they’ll be
able to
get

back to work

q
uickl
y

with a minimal loss of time or productivity
.

R
eferences

WPcandy.com: “
Does WordPress scare your clients
?”

WPcandy.com: “
Five ways to familiarize clients with WordPress
.”

S
uggested

readings




WordPress access manager
.”




6

M
ERGER
/T
AKEOVER

A massive tech mogul acquires
WordPress

and begins integrating content into its own
single silo.

T
HE
I
SSUE

An Internet behemoth decides it wants to expand its business into the world of blogging.
Instead of creating their own platform through a self
-
designed interface, they've decided
to simply absorb the leading player in the industry, WP. The company is absor
bing WP
in its entirety without changing much in the structure of the organization, so WP content
strategists now have to work to keep its content management intact while integrating
with their new overlords. Facebook set a precedent for this kind of CMS c
ompany
acquisition when they bought
Inst
agram
, so this is a realistic scenario for WP.

V
ARIANT
1:

I
NTEGRATING
B
USINESS
L
OGISTICS
/P
RACTICES

There are a number of companies that could have an interest in acquiring WP, and
each would provide a different set o
f challenges in terms of company policies and
content integration.

Causes

Ultimately, the causes for being acquired have relatively little to do with anything the
CMS/company itself did wrong. If anything, it is a lack of mistakes that make WP a
target. WP

is good at what it does, but a company with lots more money behind it could
develop an interest in diversifying its business model, and that brings WP into the
crosshairs.

Pre
-
conditions

Since WP is not (yet) a publicly
-
traded company, a major
precondition of this scenario is
that WP would have to agree to a buyout or become publicly
-
traded in the future.

Problem

There are obviously challenges associated with any company merger, and this is no
different. There will be logistical challenges conce
rning how the company is structured,
how company resources flow from place to place, and how the larger company’s
policies are integrated with WP’s existing ones.

Example

If Google buys WP and wants to create a WP branch in Google’s home office, how does
W
P staff it? Hire more employees? Restructure the company? How do they get Google
employees acclimated with WP’s work practices and vice
-
versa?



7

Consequences

A poor integration strategy would result in a massive loss of resources, employee
frustration and
resulting lack of employee buy
-
in. If these companies are going to merge
their places of business or work practices, a lack of set guidelines or goals will cause
mass confusion and organizational dysfunction.

V
ARIANT
2:

I
NTEGRATING
C
ONTENT

If WP is absorbe
d into a larger company, there will likely be an expectation of data
integration/sharing. How does WP balance this requirement while still protecting user
privacy and their own (already effective) content management?

Causes

Purchasing company wants to crea
te synergy between WP and Facebook platforms,
requires WP data access/integration to better achieve goals.

Pre
-
conditions

The p
urchasing company has authority (and reason) to force
-
integrate data
.
WP
must
maintain some control over where and how that data
is integrated
.

(
I
f WP has no
control, the point is moot
.
)

Problem

With two digital media conglomerates joining forces, particularly ones often dealing with
the sensitive information of millions of users each, there are going to be lots of issues
determinin
g how that data plays together (or if it should be kept separate). Does the
new company begin linking directly to WP and integrating that data to a single silo? Do
they suddenly have access to WP users' accounts? Do WP users have the opportunity
to opt
-
out
? The primary problem at play here is one of integration. If Facebook wants to
forcefully
integrate

WP data into its own systems, how does WP comply without
completely wrecking their own content strategy?

Example

Facebook wants to integrate WP user data
and link users' Facebook pages to their WP
accounts. As a result, WP has to rearrange their backend user data to make it play nice
with Facebook's CMS, and probably add some integration tools (and disclaimers/new
license agreements) for users on the WP sit
e.

Consequences

There exists the possibility for c
oncern or backlash from WP users.

Da
ta
could
potentially be lost or

compromised in transition

References

CNN.com: “
Instagram's passionate users wary of Facebook takeover

NY Times Dealbook: “
Facebook
b
uys Instagram for $1
b
illion


8

Suggested
r
eading

WP User forums

As the integration with the new company progresses, it will be crucial for WP (and its
new parent company) to keep track of
what loyal users are saying, what they want, and
most importantly, what they don’t want.

S
TRATEGY

Set
g
round
r
ules
p
rior to
m
erger

Because WP is privately
-
owned, they would have to agree to any buyout offers, which
means they also have the power to set pre
-
conditions regarding what the company in
question can and cannot do. Therefore, they can control some elements of the merger
by laying ground rules and conditions prior to agreeing to the merger.

Tactics

1.

Determine goals of the merger. Allowing a buyout by

a larger tech company will
bring both an infusion of money and resources to the company. If company
structure and autonomy is still important, determine what benefits WP should
look for from its new parent company.

2.

Determine content integration strategies

before merger. If WP wants to remain a
separate entity and wishes to keep its data separate from a Facebook/Google
silo, it has the power to stipulate that as a condition of the merger. If WP is willing
to integrate that data, they can specify how.

3.

Develo
p ground rules for user data. Does the parent company get access to WP
user data? If so, what are its abilities/limitations for that data? And what say do
the users get in this?

4.

Develop a strategy for handling PR, particularly surrounding user concerns. On
e
of the most important things for a company dealing with this kind of transition is
to not alienate loyal users. That means protecting their privacy and taking steps
to explain what changes are coming and what new features may be available.


R
EFERENCES

Facebook's mobile plans (Part 2): Instagram's independence vs integration

Facebook helps Instagram with unique Open Graph app rollout


What Faceboo
k's acquisition Of Instagram means for brands

Suggested
r
eadings:

User
a
ccess
m
anager

Four
l
essons for IT
i
ntegration
a
fter a
m
erger and
a
cquisition



9

D
EATH BY
P
LUG
-
IN

One of the major affordances of
WordPress

as a CMS, is its open
-
source platform,
where developers and users are free to modify, expand, and improve its design through
easily available and accessible source codes.
WordPress

invites its users to participate
in programming, design and docum
entation, which is one of the many reasons why it
has built such a strong community of developers who are dedicated to improve/expand
Word
P
ress’s

functionality and usability. One of the most valuable ways that users have
leveraged this open
-
source philosop
hy is through the creation and use of plug
-
ins.

T
HE
I
SSUE

Word
Press’s

extensive plug
-
in catalog allows users (both experts and non
-
experts) to
break free from the traditional “blogging” platform that it offers “out
-
of
-
the
-
box,” to create
sites with varyin
g purposes and functions. However, although the diversity of plug
-
ins
makes
WordPress

an advantageous CMS for a many different user needs, the amount
of plug
-
ins available and their subsequent implementation onto
WordPress

sites can be
problematic.

V
ARIANT

1:

P
OOR
S
ITE
P
ERFORMANCE


Although
WordPress

has a rich plug
-
in architecture, there can be (especially in
conjunction with non
-
it specialist users) difficulty in choosing, and ultimately
implementing more than one plug
-
in to run smoothly on their sites.
When users don’t
know what plug
-
ins are compatible with others or how many they can successfully run
on their site, this can cause major issues in site
performance

and functionality.

Causes

Because many of the plug
-
ins
on
WordPress

are added to the database by third
-
party
developers, there is a lack of documentation on how different plug
-
ins interact with each
other and how site managers can best leverage each type of plug
-
in. Ultimately,
different plug
-
ins live independently from ea
ch other, and because sites
have multiple
needs, there is a lack of documented, or traceable information on which
plug
-
ins
cooperate (and, more importantly, don’t cooperate) with other plug
-
ins
. Along with that,
there is no “serving size” information avail
able to let users know when they are running
too many plug
-
ins on their site.

Pre
-
conditions

The number of plug
-
ins users deploy on their sites is predicated on the fact that
WordPress

prides itself on offering a vast array of plug
-
ins to users wishing to
expand
the functionality of their site. Because of this, it is easy for users to overlook necessity
when choosing which plug
-
ins to use.

Problem

Plug
-
in incompatibility and monopolization of server space (i.e. one plug
-
in making sites
stop, or run slow) c
an often be invisible to site managers who chose to implement them
on their sites. Because of this, it is unclear whether some plug
-
ins will work
cooperatively with others, and consequently, some sites may start to lag or functionality
starts to get compro
mised. This is a threat to organizations that depend on the rich plug
-
10

in architecture that
WordPress

offers, but who don’t understand how to fully leverage
the mass amounts of plug
-
ins available.

Example

Many sites opt to use a
S
earch Engine Optimization
(S
EO
) plug
-
in or plug
-
ins that claim
to
help build links, attract traffic
, which is good for the site owner/manager, but these
types of functions (especially in conjunction with other plug
-
ins) become the focus of the
site instead of the content.

Consequen
ces

As a result of non
-
existing guidelines about proper plug
-
in use and recommended
number of plug
-
ins to run simultaneously, content might not be displayed correctly or in
the most effective manner possible. Another consequence is
a visibly slow running
w
ebsite, which could then lead to decreased traffic, and ultimately, an ineffectual
website. These concerns are valid for any user already invested in the platform, which
could eventually turn them away from using it for future projects in favor of somethin
g
that is more straightforw
ard with plug
-
in compatibility.

V
ARIANT
2:

C
OMPROMISED
S
ECURITY

Just as poor site
performance

is a consequence of
WordPress’s

third
-
party plug
-
in
structure, sites are also susceptible backdoor coding by hackers wishing to exploit

vulnerable plug
-
ins.

Causes

Stemming from its open
-
source framework,
WordPress

sites that use third
-
party add
-
ons run the risk of becoming susceptible to hacks because gate
-
keepers to the plug
-
in
database do not make clear, or do not put into place a qua
lity
-
control system that filters
out plug
-
ins that may be risks to site security.

Pre
-
conditions

Risky plug
-
ins are predicated on the lack of quality control of the plug
-
in library.
Because it is unclear how these plug
-
ins are vetted before becoming availa
ble for all
users, many content managers are unable to

Problem

Site managers (especially non
-
it specialists) do not generally look at plug
-
in codes

in
detail,

because
WordPress

markets them as easy, powerful ways to increase and
expand functionality of a s
ite. Because of this,
many plugins have vulnerabilities of their
own that m
ight be exploitable. And although plug
-
ins can be rated and commented on
after they have been published to the library, as with the previous variant, these
vulnerabilities are at fi
rst invisible to users when deployed on their sites, leaving them
exposed to potential hackers. This problem should be avoided before the plug
-
ins are
added into the library.



11

Example

Some plug
-
ins keep portions

of their
directories writable, which makes
them vulnerable
to hackers that track exposed directories. Because these plug
-
ins are exposed, hackers
can then directly upload backdoor code to a site’s directory easily after

gain
ing

access.


Consequences

The s
usceptibility to hacking thr
ough back
-
end coding can leave sites vulnerable to
content damage or loss. This is a major threat to site managers and organizations
because their content is directly exposed to

References

W
ord
P
ress.org/
S
upport/


Are your sites running slow?


WordPress plug
-
ins

how to know if you have too many

Suggested
r
ea
ding

WP User forums

WP Plug
-
in directory


Many users have used the forums as a springboard for discussions about the threats
that plug
-
ins engender when impl
emented on their sites. And although it may be difficult
to find documentation on how individual plug
-
ins they interact with other add
-
ons, the
main plug
-
in page is a good place to start seeing trends in the success and functionality
of different plug
-
ins.


S
TRATEGY

Make processes visible

In order to combat the issues that stem from unruly plug
-
ins, whether it’s slowing down
site
performance

or compromising security,
WordPress

should make their gate
-
keeping
practices more visible to users so they can see fi
rst
-
hand when and if there are risks
that could affect the content of their site.

Tactics

1.

Although how site
-
managers use add
-
ons in
WordPress

should not by any
means be prescriptive, there should be more visible ways of letting users know
when their plug
-
i
ns have reached a moment of saturation

2.

As for compromised security,
WordPress

should have a better vetting system
that tracks plug
-
ins that are susceptible to hacking and exploitation. Looking back
at plug
-
ins that were threats to security and seeing how they were structured can
help to prevent future plug
-
ins with potentially fata
l (to content) outcomes.

References

Threat Scan
p
lugin

Suggested
r
eading

Maintain
k
iller
s
ecurity on your
b
log by using one WordPress
p
lugin