Securing Customer Support

Once your startup is successful, you’ll build tools that access customer data. The risks of this access increase as a startup becomes successful.

• Engineers build support tools to fix customer issues.
• Those tools become more powerful as customer issues grow.
• Scale pushes support towards an outsourced or remote workforce.

Let’s explore this area of risk with the abbreviated approach described in “From Scratch”. This example is largely inspired by a conversation I had with a startup that manages money on their customer’s behalf.

Publicly Known Incidents

Before we categorize our threats, lets start with some real world examples.

• Coinbase employees were targeted by attackers who social engineered Verizon Customer Support.
• GoDaddy and PayPal are social engineered to allow an attacker to takeover an individuals domains, email, and social media accounts.
• Apple and Amazon customer support failures lead to a personal data wipe of Mat Honan. More, Amazon leaks enough information to allow a fraudster to commit identify theft against a customer.
• Old school AOL had a history of issues with screen name takeover, and private data leaks.
• SendGrid customer support is tricked, and forced to BCC an attacker on password reset emails.
• Bitcoin company suffers a loss after their hosting company’s support team violates their own password reset policy

We can begin forming predictions after reviewing public example. After considering the risks at your own company and involving your own risks, we can organize these threats into something useful.

Threat Models

We can do our best to to enumerate threats against Customer Support, and bucket them into five threat models that stand out. Our earlier homework will help prioritize them, next.

Customers are fooled.

An attacker successfully fools a customer to believe they are communicating with support, but are not, and the customer is then victimized.

Most classic phishing scams impersonate a brand and have a similar impact. This threat greatly increases at any company with a large, active user base that interacts with a platform you maintain.

Mitigation ranges from brand protection and anti-phishing to awareness campaigns to ensure your users can easily find the “right” way to converse with you. The area of “Account Takeover” fits into this as well.

A support employee has gone rogue.

An employee decides to benefit themselves with their access to your company’s custom tools.

There is little public data on how often employees on large support teams abuse their access. Among the incident response community, it is pretty well accepted that all companies that have become sizable will have fired at least a few people for abusing their access.

Mitigation starts with hiring trustworthy employees who are well invested in the company and can pass a background checked. Though, this can become prohibitively expensive and eventually equity grants lower.

To bolster this, you can promote your ability to investigate abuse (logging), set clear expectations (training and a signed “acceptable use policy), and build tools that separate duties so that a single bad employee can’t cause a disaster.

By far, the most effective controls against insider abuse have been clear transparency between teammates and clear warnings about the data they want to access, when they access it.

Example: If an evil employee is about to issue a large refund to one of their friends, an inline head’s up reminding them of their responsibilities is a great deterrent. Especially if they know their peers may see this activity in a team wide feed activity feed, they may be less certain they could get away with it.

Support employee has been fooled.

An attacker is impersonating a customer to victimize your support team.

The bulk of most public data (including almost all of the examples above) fit into this threat model. Most larger teams that support a large user base are extremely familiar with scammers and have a hard time keeping up.

Training is the most applicable mitigation, especially teaching employees how to escalate and making sure escalation paths are OK. Sometimes reinforcing “ask security@” instead of teaching a long list of rules is a much more effective use of time.

High quality training makes use of feedback loops: Be sure the team blasts out knowledge of any new fraud schemes or social engineering tactics to the entire group. It can be the support team’s job to gather up these stories and re-train on them every week. Praise anyone who discovers a more sophisticated scheme than was previously known. Encourage these stories to become more than documentation and become tribal knowledge for the team.

For high value / high risk operations, be sure to design tools that strictly require the same protocol to be used repeatedly and avoid the wrong thing from happening 5% of the time and causing a problem.

Support employee is breached.

An attacker has taken control of the employee’s endpoint used to support customers.

AOL has the most well documented history of Customer Support employees being targeted and hacked at the endpoint. This is not as common as social engineering attacks. This is simply because of ease of access: malware on your support team’s laptops would be much more valuable for a persistent attacker, so it shouldn’t be ignored as a possible threat, but should be carefully prioritized against the volume of social engineering attacks that are well known.

Mitigation mostly lands in a largely well understood endpoint security strategy for a company.

Your tools are breached.

The tools used to assist customers have a vulnerability and are compromised.

The most famous example of this includes the “happiness” breach at Twitter, where administrative tools to support users were exposed to the internet and protected by single factor authentication. The FTC came down on Twitter very, very hard after this. While there is not a pandemic of support tool breaches to point at, it is deeply embarrassing and a large regulatory risk.

It’s also very easy to identify your weaknesses against this threat. If your support tools are accessible over admin.yourcompany.com and protected by simple password authentication, you’re asking for trouble. Otherwise, mitigations here land in the application security space.

Prioritization

Now we’ve hopefully done all of the research on known threats and our own risks. There’s two groups to consider, narrow and wide risks. A narrow risk requires a very specific mitigation that can’t be used well elsewhere. A wide risk is reduced by very high impact mitigations that are valuable elsewhere as well.

Narrow Risks

These risks are unique to the subject area (customer support) and other parts of a security program will be unlikely to manage these risks well.

1. Support employee has been fooled.
2. Customers are fooled.

There is clear data that shows how accessible and successful social engineering attacks are against a support team. However, most other security efforts around the company cannot help mitigate this risk. It is a largely unmitigated problem unless special attention is given to a special risk.

So while the threat is specific and significant, this has to be measured in comparison to more systemic risks with higher impact mitigations.

Wide Risks

These risks should see significant mitigations elsewhere in a security program that are totally unaware of the risks in customer support.

1. Your tools are breached.
2. Support employee is breached.
3. A support employee has gone rogue.

These risks do not require mitigations that are specific to customer support if you have larger efforts around application security, endpoint security, and training about acceptable use of information. These risks are part of a whole constellation of risk that are mitigated by a single endeavor.

For instance: Improving endpoint security or application security would have a significant risk reduction, completely agnostic of what risks Customer Support faces, specifically. Other organizations have risk of their endpoints being breached as well!

This means that the mitigations for wide risks will frequently be a higher priority than narrow risks.

Exceptions to this certainly exist, but they should come with a solid argument.

Conclusions

This leaves us to make conclusions on how we would prioritize the security of customer support. Each reader will approach this differently.

Bias towards prioritizing the wider risks. Mitigating these risks would have company-wide impact, and reduce massive amounts of overall risk with individual mitigations.

The next priority would be to address the more narrow risks, like specifically training a support team to understand and escalate social engineering. These narrow risks should not take away from efforts to mitigate the wide risks, but significant ones should not fall off the radar altogether.

For example: If you’re small, you have the advantage of training a small support team, and might take a day or two. A wider mitigation like endpoint security would always take far more effort. So it would be important to tackle a training opportunity while small, and not punt on it so long that it becomes high effort later on.

Lastly, failure is frequent and common. Prepare for the inevitable breach.

@magoo

I’m a security guy, former Facebook, Coinbase, and currently an advisor and consultant for a handful of startups, including HackerOne. Incident Response and security team building is generally my thing, but I’m mostly all over the place.