3 Real-Life IT Horror Stories That Illustrate Dangerous Blind Spots in SaaS Environments

As the adage goes, “You don’t know what you don’t know.”

And that’s especially true when it comes to managing SaaS environments. SaaS administration is an emerging area of IT—there is no established best practices, no official certification. According to our last webinar poll, 59% of IT professionals are teaching themselves how to manage SaaS apps, and 19% are just getting started. Increasingly, IT teams are running into unforeseen challenges and realizing that there are critical areas—aka blind spots—they have no visibility into.

Here are 3 real-life horror stories that illustrate major blind spots in SaaS environments and the damage they can cause: embarrassing data breaches, devastating data loss, and more.

Horror story #1: That time a fired admin used his still-active passwords to steal employee passwords and put porn into his ex-boss’s PowerPoint presentation

Um… well that’s certainly one exxxciting way to exact revenge.

This horror story illustrates the importance of proper offboarding. Here’s why.

52-year-old Walter Powell, the IT director at Baltimore Substance Abuse Systems (BSAS), had just been fired. To his delight, he discovered his passwords still worked. So he decided he’d wreak some havoc.

According to NBC, he spent at least 32 days post-firing “hanging out on BSAS’s computer systems.” He installed keylogging software to steal employee passwords. He wrote emails to the entire company pretending to be the CEO.

But his final blow involved slipping porn into the CEO’s presentation while he was presenting to board members:

“It happened one day last year, as more than a dozen board members of a Baltimore substance abuse center had gathered around a conference room. The CEO was giving a PowerPoint presentation on his accomplishments. Suddenly, his computer shut down, then restarted, replacing the latest slide with an image of a naked woman onto a 64-inch screen. The board members include city officials and foundation heads and is chaired by Baltimore’s health commissioner.”

Yikes. Of course, there are far worse things that can happen if ex-employees retain access (like the ex-sysadmin at Georgia-Pacific who used his previous accounts to cause multiple system failures, leading to $1.1 million in losses).

But this story nevertheless represents a major blind spot for SaaS administrators. How many ex-employees still have active passwords to their SaaS apps? How many still have access to corporate data? How would you know if they were still logging in and accessing your data? There’s no easy way to tell.

How to avoid this horror story: Enforce offboarding policies and make offboarding a priority. Make sure you revoke data access for all exiting employees across all their SaaS applications. This admin’s passwords should not have been active after he left the company. Had he been properly offboarded, this entire sordid affair could have been avoided.

Horror story #2: That time hundreds of Google Groups were accidentally made public on the internet, exposing PII and private emails to the world

Last year, a very simple settings misconfiguration in the Google Admin console led to sensitive data exposure for hundreds of companies.

According to ZDNet, researchers found that email addresses, email content, PII including employee salary compensation, sales pipeline data, customer passwords, names, and home addresses at hundreds of companies were exposed publicly for the world to see.

How did it happen?

Very simply. When Google Groups are set to the “Public on the internet” setting, messages sent between members can be viewed publicly by anyone on the web.

This misconfiguration just takes one click. The difference between making your groups “Public on the internet” (meaning anyone on the internet can view, search, and post to groups) or “Private” (meaning nobody outside your domain can access groups) is just one small radio button:

“This incident shows that a simple oversight of one setting can potentially have devastating effects for businesses,” writes ZDNet. “Should this corporate information be utilized, corporate accounts could be hijacked, information can be mined for phishing attacks, and sensitive conversations not suitable for the public sphere may be leaked.”

This is another major blind spot for IT administrators in SaaS workplaces. Is any of your organization’s data publicly exposed through your Google Groups? If an admin accidentally made all of your organization’s groups public on the internet, how would you know? How long would it take you to discover this exposure? IT has no visibility into this area.

How to avoid this horror story: Check your Groups settings in the Admin console (click here for instructions) to see if any of your groups are public—and, if necessary, remediate it to lock down sensitive data. 

Horror story #3: That time Stanford University suffered three separate data breaches, exposing personal employee info and student sexual assault reports due to “misconfigured permissions”

Last year, Stanford University suffered three separate data breaches. Personal employee information, confidential financial aid, and student sexual assault reports were exposed.

The incidents were due to “misconfigured permissions” on online file-sharing platforms including Google Drive.

According to Palo Alto Online, “In one breach, a file containing names, birthdates, Social Security numbers and salary information for nearly 10,000 non-teaching university employees from August 2008 was exposed on the Graduate School of Business’ server. The file had been used for annual salary setting. The folder’s permissions were changed last September, making the file ‘inadvertently accessible’ on the business school’s shared drive, Stanford said. The file was exposed to the Graduate School of Business community for six months before it was locked and secured last March.”

Similar to the Groups horror story, default file sharing permissions are very easy to misconfigure—all it takes is a simple click in the Admin console.

Unfortunately, these incidents are not uncommon at all. A similar breach happened at the University of Oklahoma last year when student records were unintentionally made public on mail servers due to “a misunderstanding of privacy settings.”

This is a particularly insidious blind spot because files can remain exposed for months without IT knowing. What’s the default sharing setting for your files across SaaS apps? How would you know if your domain’s files were suddenly shared with everyone in the domain (or worse, publicly)? How long would the exposure go undetected? In Stanford’s case, the data was exposed for six months before someone realized what happened.

How to avoid this horror story: Check your link sharing settings in the Admin console (click here for instructions) to see what your link sharing defaults are—and, if necessary, remediate it to lock down sensitive data. Additionally, implement the principle of least privilege by minimizing the number of super admins. The fewer super admins (i.e., people who can make these types of changes) you have, the less risk you’ll have. 

What do all of these horror stories have in common?

They all represent security blind spots in SaaS environments—areas where IT has no visibility. IT teams aren’t even aware that these security threats exist until it’s too late. These horror stories are just a few of many out there, and more will continue to crop up as SaaS continues to gain widespread adoption.