If your support staff need backdoors into customer accounts to provide support, then you need to safeguard that access beyond authentication and trusting staff alone.

Note: If you’re a SaaS buyer 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. The accounts were breached via an internal support tool.

Here’s the most important takeaway from the breach: SaaS (software-as-a-service) companies build proprietary software platforms and they need internal custom tools to support that software. System administrators and support staff have always been targets for hackers; giving support staff powerful tools without a lot of protection makes them juicy targets for criminals.

Years ago, a friend of mine worked at a bank as a customer service representative. They had access to every personal banking account at that institution. That level of access was appropriate for the role, any customer could call in for assistance. The bank had notable customers and they flagged those accounts for unauthorized access; I remember my friend telling me of a colleague being fired for accessing a famous politician’s account without authorization. That was twenty years ago so this is a solvable problem assuming there is the money and desire to do so.

These internal 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 rigour, less support, less security, less development resources. Only the largest SaaS providers will have engineering teams dedicated to building and supporting these internal tools. For most SaaS companies, especially startups, the tools are bare bones at best.

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. Trusting that staff won’t abuse the access is not a scalable control; trust often fails.

If you are building internal support tools - and you will - then here are ways to secure your internal support tools.

If you’re a small startup in MVP mode then you probably don’t needmuch internal tooling yet but you can do the following:

• Limit access to production with Gravitational Teleport (an SSH replacement) or Okta Advanced Server Access;
• Log all interfaces (send logs to S3 secured with write only policies);
• Educate your team on both security and privacy issues;
• If you need to look at or manipulate production data; do it as a pair (programming) exercise. Make it clear to staff that access to user data in any other context will get you fired; and
• Be religious about who has access to production data; you’re probably a small team so there are lots of hats but check periodically and take it away if that access is not needed. You can always give it back.

Credit to my friend Brian for the above.

If you’re early stage profitable then you’re probably building (or already have) a simple tool so that the customer support staff don’t bug the engineers for frequent problems:

• Do all of the above but maybe buy better tooling and get more serious about who can access production;
• Your internal support tool should be strongly authenticated and only accessible via a jumpbox or VPN;
• Log all use of the internal support tool;
• Have the head of customer support periodically review a sample of the usage logs and follow up on anything unusual;
• Limit what the tool can change or see - if it’s something contentious then it’s worth it to have it go through Engineering. A little slower and more effort, but provides a safeguard. Avoid just dropping a web GUI onto the database allowing any field to be accessed; and
• Set clear policies on what can and cannot be done with the tool and educate support staff. Remind support staff that they are a target for social engineering as well.

If you’re a bigger SaaS platform then consider doing the following (on top of everything before):

• Make sure access to the tool is strongly authenticated with multi-factor and that authorization limits the capabilities of the tool in a way that is appropriate for the role. Some support staff need to see certain information but not at all; other may need the ability to make certain changes but not all possible changes;
• Consider additional restrictions on use, such as requiring that access be done from corporate-owned devices.
• Restrict certain types of changes and access to either require user permission (via a link sent to their email account) or require a second set of approvals from a colleague;
• Automate alerting if the customer support representative (or whomever is using the tool) makes more than a certain number of changes in a given period of time. It may flag top performers but that’s not a bad thing;
• Notify the customer whenever access occurs or changes are made; both by email and at the next login;
• Require and validate valid ticket numbers or tracking numbers be assigned to use of the tool;
• Reduce the functionality of the tool to support specific use cases. Make the tools do less and limit what support specifically needs to do. It’s yet another way to enforce the principle of least privilege; and
• Have regular reviews, supported by automation, of use of the support tools.

It may seem like a lot but security is only as good as the weakest element. Your customer’s trust you with their data; if you give your support staff powerful tools then you owe it to your customers to make sure those tools are properly managed by designing them properly and safeguarding their access through education, awareness and proper governance. It’s not only going to take good tooling, it will take culture change to convince people to move away from “we trust everyone” to “we need to make sure unauthorized access can’t happen”.

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