Changing the locks

This is the first blog in a four-part series delving into information security concerns and what you can do to keep your organisation safe.  

The LA Times hack

In December 2010, the LA Times website was defaced by a member of the Hacktivist group Anonymous. Unusually, this defacement required no special hacking skills or tools to accomplish. The hacker had been given a username and password and was therefore invited to cause destruction. The person who gave him the password worked at a TV station, whose parent company was also the parent company of the LA Times. They shared the same CMS.

The defacement wasn't notable. A fairly minor political article had its title and attribution changed. The problem was found by staff within forty minutes and was fixed three minutes later.

However, it could have been much, much worse.

Whose fault was it? 

Of course, the disgruntled ex-employee is to blame for providing his username and password to the hacker. That is not in doubt.

What is interesting, though, is that he'd left the company two months earlier and his username and password still provided him with access to the system from anywhere on the Internet. His account should've been disabled when he tendered his resignation or when he was given a box to pack his things. That places the blame on someone else's shoulders as well.

Who feeds the cat?

Unfortunately, in large organisations with large bureaucracies, or in small organisations with no bureaucracies, it's difficult to maintain clear lines of responsibility. It's like the old saying "if it's everyone's job to feed the cat, the cat will starve."

In this instance, was the responsibility to disable the account with HR or with IT? Was it with the TV company or with the parent company? Clear lines of responsibility and clear procedures around staff departures would have prevented this incident from happening at all.

Keep your hands to yourself?

Why did the defendant have access to the LA Times content? He worked for a TV company.

Why did they share the same CMS? Why weren't there permission structures in place to prevent employees from one company editing the content of another company?

Why wasn't there a workflow in place where content changes to LA Times public website content were approved by an editor before going live?

What can we learn from the LA Times hack?

Security is achieved through a balance of organisational policies and procedures and technological controls.

Ask yourself the following questions:

  • Do we have clear policies and procedures for when staff depart the organisation?
  • Who is responsible for 'changing the locks' when people leave?
  • Do we restrict where users can access the backend access from?
  • Do we have effective permissions in place so that users can only change what they should?
  • Do we have effective workflows in place so that content is properly approved?

If you don't have answers to those questions, or if they're not satisfactory, it's worth raising. If someone at the LA Times had, they wouldn't have been hacked.


Back to the top of this page