A Treehouse of Security Horrors

Fans of the television show The Simpsons look forward each year to the "Treehouse of Horror," its annual Halloween episode. From Maggie – the baby – being possessed by a demon to Groundskeeper Willie being killed three times by an ax murderer in a single episode, the horrors get more intense each year and keep the viewers guessing.

When that Halloween episode rolls around every year, some cybersecurity professionals will be reminded of true-life horror stories they've experienced working in the field. The Simpsons is fiction, but people acting possessed and otherworldly in our everyday lives can leave companies open to more sophisticated hackers and insider threats.

Here, I'm sharing several "episodes" from what might be dubbed our first-ever "Treehouse of Security Horrors," along with a bit of advice for avoiding nightmares like these inside your own organization. These are all true-life horrors from conversations with software engineers and developers, as well as my own stories from the front.

Alien invasion: A company saw its website hacked because login credentials were stolen from a third-party, overseas developer. Hackers were able to gain root access and planted a piece of software for stealing credit card information.

The company could have avoided the resulting horrors by ensuring that whatever sensitive data a third party needs access to is stored as securely on the outside developer's network as it is on the host's. Too often, credentials are dumped into a text file, which makes them easy to steal. An extra couple of layers of security, such as a secure way to share credentials, would have helped. Instead, the forensic IT investigators that the company hired found that there wasn't proper monitoring on the company's own servers.

Security needs to be like an onion. An intruder might be able to pierce an outer layer, but that only means facing an additional sequence of defenses before reaching a company's core operations. In this case, a company's nightmare was lost business and extra expenses totaling tens of thousands of dollars.

Exorcise your demons: One IT developer was still a member of internal Slack channels at a former employer six months after leaving that company. This lapse is more about potential horrors, starting with an embarrassing scenario when ex-employees have access to exchanges that employees believe are private conversations within the company. The developer didn't take advantage, of course. But the risks would include a company inadvertently giving away trade secrets and other proprietary information to a disgruntled ex-employee — or, worse yet, one who went to work for a rival.

Members of internal Slack channels have been known to share highly confidential or otherwise sensitive information. That includes credentials providing access to one or more internal services, which could give an attacker a launch point from within a company.

Demons that haunt your dreams can be avoided when a company recognizes the many potential access points employees have into a company. A recent survey we conducted showed that 77% of IT and DevOps workers said that they still have some access to their former employer's technical infrastructure or development environments.

I'm a prime example: For a company where I last worked a half-dozen years ago, I still know the root password to its most sensitive server. Good thing I'm no Mr. Burns, right?

But of course not everyone has that much integrity. These keys must be disabled whenever an employee departs. Think of it as changing the locks when renting a property to a new tenant. When a person leaves a company, make sure to disable every key they have into your business — whether it's the access they have to Slack and other collaborative services, or the API keys in the hands of former developers.

A poltergeist in the cloud: The bad habits of contractors and partners can haunt a company unless it insists on better security among the third-party people it works with. I've heard too many stories in my 20-plus years in the business of third-party players who have access to a company's secrets but are far less vigilant about protecting them.

In one instance, a contractor left a company's AWS keys (the APIs for accessing the server space it rented from Amazon Web Services) on a public source code repository like GitHub. Those with bad intentions employ automated software to scan for these kinds of jewels in public repositories and then use them to their advantage. In this case, the miscreants harnessed roughly 100 AWS servers to do their bitcoin mining, and in the pay-for-what-you-eat world of cloud services, the company ended up being on the hook for all of that usage.

The financial impact to this customer was significant. The damage would have been limited had this company had in place a cap on its usage on AWS. But the real problem was that a valuable secret was not properly managed. The fact that the offending party in this case was a third-party contractor only underscores the point that organizations need to address the risk of granting third parties access to sensitive information. My advice: Provide security training to any contractor who falls into that category and vigilantly watch for problems on that front.

Otherwise, you might find yourself in your own treehouse of security horrors.