Are you asking your vendors about the capabilities of their internal support tools?

Note: If you’re a SaaS vendor then check out the companion to this article

On July 15th, 2020, Twitter had a bad day. More accurately stated, several of their most prominent users had their accounts breached. These high profile accounts were used to broadcast a bitcoin scam that compromised 130 accounts and netted a little over $100,000 for their efforts, which was considered a pittance compared to the potential of a more sophisticated malicious use of those accounts. Brian Krebbs and others provide a good summary of the events. Twitter themselves is setting the bar on how companies should be transparent and fast in their breach communications. It’s a great case study and highlights the importance of making sure your customer support staff and tools are well secured. I think that there’s a story behind that though, specifically, the security of customer support tools.

130 accounts were compromised of which 45 were used for the bitcoin scam and 8 had their information stolen. For the most part, this breach had no impact on the corporate world; perhaps corporate social media accounts just weren’t popular enough from the scammers perspective. Corporate information security teams breathed a sigh of relief: no risk to us, bullet dodged, Twitter contained the breach, read the excellent post mortems and life moves on.

Here’s the other part of the story: SaaS (software-as-a-service) companies build proprietary software platforms and they need internal custom tools to support that software. These tools are part of the service delivery itself. They are used to modify settings, access data and impersonate the user to aid in troubleshooting. These are not tools you can buy; they have to be built. These support tools fly under the radar, just part of the service one contracts for; they’re deep inside the company and their existence is not broadcast to customers.They are not revenue generators and may suffer from being “shoemaker’s children”; less rigiour, less support, less security, less development resources.

Not all SaaS vendors have security testing reports but for those that do these custom support tools are typically out of scope. The limited scope of security testing reports may lead to a buyer believing the security to be adequate when there’s a back door that is less secure. Vendor assessment security questionnaires don’t often ask specific questions that would uncover the existence of these tools and software vendors are not likely to volunteer the information unless pressed.

Even if these support tools are well constructed and supported, they still provide a customer service representative with a potential back door into every account or tenant on the SaaS platform. Custom support tools need to be part of the security evaluation scope for buyers.

If you use SaaS platforms that process private or sensitive information then you need to ask the following questions of your vendor:

• Do you have internal support tools and what are their capabilities?
• How do you secure back-end privileged access to customer accounts and customer data?
• How can customers control under which circumstances their accounts and data can be accessed by internal company agents?
• How do they determine if usage is legitimate?
• How is the security of internal support tools tested?

That your SaaS vendor has custom support tools isn’t bad, it is a necessity for providing support for users. These tools can provide a safe interface to support customers if done properly. If your vendor does not have such capabilities codified as support tools, consider that they may be doing something less scalable, such as allowing vendor support staff direct access to production databases. However, if they do have internal support tools, it’s important you understand how they impact the security model.

With thanks to a ragtag bunch of friends for edits and ideas.