Customer Service and Security: What Not to Do
I recently signed up for a financial service so I could pay my awesome editor and writing coach, Matthew Sweet. Matthew is in the UK, but I’m in the US, and while it should be easy to pay someone on a different continent, it actually isn’t. The simplest ways incur huge fees, major delays, or both. I’d love to just pay him via Square, but they don’t currently support global payments.So we’re trying out a different service. One we’d never heard of before. One whose sole purpose is to facilitate international payments while keeping fees down. Sounds great!
We both created accounts and the company collected our bank account information. There were no glaring security issues. Pages and links were encrypted. And since I didn’t feel like trying to break into a financial service’s website, there was no way to tell what was going on in the back end.
A few days later I received an email from the company. They told me that my bank account didn’t match the name I’d provided, and asked again for the name and address on the account.
As I read the email I noticed that the page collecting the information was served over HTTP, not HTTPS. It wasn’t encrypted. I then checked the link the form would be submitted to. That was also not encrypted. This meant that the form could be tampered with before I saw it, and that the information I supplied could be eavesdropped upon and tampered with.
Let’s keep this in perspective. This isn’t an enormous issue or an emergency. It’s not like they have a web page sitting out in the open showcasing their customer’s account information. But it is sloppy, and it reduces the confidence I have in this financial company’s ability and willingness to handle my information with care. There’s no excuse for them not to encrypt everything that moves between them and me. They should protect every shred of information about their customers, including who their customers are. Potentially exposing names and addresses is not okay.
How Not To Design Customer Service
If you’re a company that may receive security-related reports, the first thing not to do on the customer service front is to make it difficult to report issues.
In this case, the company has a link to its “Security Center”. It outlines what the company does to protect data and includes the statement, “All of your personal data, as well as each transaction, is protected by strong encryption that makes data unreadable.” – which isn’t completely accurate. It also suggests a few ways to better protect yourself. But the only contact link it contains is for the reporting of fraud or identity theft.
The next step is the Support Center. It’s mostly self-service, and contains a detailed list of issues about which you can contact the company. This is good practice; the issues link to short pages of instructions which can resolve most customer service requests. First tier customer service spends most of its time responding to questions that are answered on the website, using scripted replies; these are shortcuts to those replies.
| Unfortunately, there’s no obvious way to reach them about security-related issues. The closest is “My Online Account | Security Issues | My account is hacked”. I chose that because there was no other way for me to contact them about anything relating to security. I wrote a quick message apologizing and saying that my account hadn’t been hacked, but that they had no other way to report security problems. I then explained the issue (un-encrypted communication), included a link and outlined the vulnerabilities. |
A few hours later I received a reply assuring me that the link was sent by the company and that the website was secure. The message directed me to contact them (but how?) if I would like to have more details. It’s clear that they misunderstood and thought I was asking them whether their email was phishing spam. They didn’t appear to realise that I was reporting a problem, not asking a question about their security practices.
I replied, explaining that the page really wasn’t secure. And I shared some of my background to try to demonstrate that I’m someone who has a clue whether a page is secure or not. But I have no idea whether that email actually reached their support team. The email I replied to said nothing about how to continue interacting with them, and I received nothing in response to my reply. But I did receive a “How did we do?” type of survey, which I filled out honestly and used to explain the problem again.
A week later I received a follow-up email quoting my reply to their first response. This email went on for several pages, describing how secure their web site is and all the things they do to secure it. There was no sign that they had actually read or understood what I’d tried to tell them. So I replied again, asking to be escalated to someone who didn’t have to work from a script and could handle a security concern. Yet again, there was no response or sign that they’d received and acted on my report.
Why Does This Happen?
Customer service serves two masters: the customer and the business. It provides an organized interface that customers can use to more easily understand and utilise a company’s offerings, and that the business can use to discover and mitigate problems and blind spots.
The majority of customer service requests can be easily handled by scripts. In most cases, they could even be resolved by the customers themselves, providing they know of and read the self-help documents most companies post on their web sites.Only a small fraction of requests need human intervention: things like billing issues and account resets.
The fraction of requests that report bugs or security issues is likely the smallest. That doesn’t mean those requests are not important. In fact, handling them well can be critical to the business’ success.The number of requests which identify real bugs or security problems, instead of highlighting simple user error, is a fraction of a fraction.
All businesses must confront serious problems from time to time. They may be operational (some server has crashed, or there are billing issues) or they may be software-based (new features not working properly in all cases, or new features accidentally breaking old features). But all businesses also don’t want to waste time on pseudo-serious problems.
Why? Because developer time is valuable. No employer (or developer) wants to spend all their time reviewing every reported bug and security issue. Yet it’s important that developers do see the fraction of a fraction of the reports which are accurate. That’s one of customer service’s jobs: to identify the few accurate bug and security reports and make sure they’re passed on to developers to correct.
How many times do you need to tell a customer how to reset their password? Exactly once. You can then reuse that response with other customers. Most customer service responses are like this: scripted. The first tier of customer service agents will spend most of their time replying with pre-written answers. But often businesses go too far trying to protect developer time. When you contact customer service multiple times about a problem, each time getting a canned reply and feeling like you’re beating your head against a wall, you’re dealing with a company that’s been too zealous in having customer service protect its resources.
These companies build customer service like a stone wall around the company, guarding it, when really they should be constructing a two-way permeable cell wall. A membrane that allows information from customers to flow in like nutrients, nourishing the company.
Without built-in pathways to identify and handle the small fraction of valid bug and security reports, customers reporting them will have frustrating, fruitless experiences and businesses will be denying themselves valuable information.
Some companies have no pathway to report bugs or security problems because they believe their own bullshit: “Our web site is totally secure, there are no bugs”. I would back away slowly from anyone who claims this, then find an alternative.
What To Do Instead
Google does a very good job on this front.You can easily find Google’s page for reporting security vulnerabilities by googling, “report a security issue to google”. It’s the first result.
And Google doesn’t assume that the reason you want to contact them neatly fits into the categories they list, so they provide you with an “other” option.
They also value security reports as they make it clear that they have a “Vulnerability Reward Program”. They’ll give you stuff for pointing out what they’re doing wrong.
Be like Google: provide a clear way to report suspected security issues. While your company may have a world class engineering team, remember that mistakes happen and things sometimes get overlooked. Your goal is to expedite reports about security issues while weeding out the mistaken reports and problems that can be handled by scripted responses. There are a few simple ways to do this.
- Always allow for “Other” reasons to contact customer service. Customer needs will not always fit into a rigid, pre-determined response hierarchy.
- Make it clear how to follow up to a customer service response.
- Internally, develop a clear process for handling security-related reports
- When you receive a report of a vulnerability, ask for more detail if needed and pass the report on to someone who is qualified to assess it. Responding with “our system is secure” is just going to piss off people who are trying to help your business by letting you know about problems you need to correct.
Extra Credit
Some companies (like Google) actively encourage outsiders to test their security and report issues. They have very clear instructions on how to responsibly and ethically report vulnerabilities and bugs, and they offer rewards (“Bug bounties”) for successful, accurate reports.For instance:
But why do they do this?
Answer: they are responsible companies, and responsible companies test their products. A lot. They build test suites, run automated and manual QA testing, and they do regression testing to make sure that old, fixed problems don’t return. But no matter how much testing they do, and no matter how good they are at it, testing won’t be foolproof.
The people devising tests for software are generally quite familiar with the software they’re testing. It’s usually relatively easy to test for proper operation of the software (“does 2+2 = 4? yay!”). But the most interesting bugs, and many security issues, arise from fringe conditions where things don’t go as anticipated by the developers (“what does 2+? equal? aieeeeee”). Because these conditions are, by their very nature, unanticipated, they’re also likely not tested against.
Test scenarios have a difficult time encompassing the wide spectrum of real world conditions that software runs under. During testing the system may only have a few simulated or real users, following scripts. In the real world, thousands of users may be doing almost random things simultaneously.
This leaves developers in the difficult position of having to anticipate everything a user might do, whilst knowing the system too intimately to see what they may have missed. Meanwhile, external real world users (and attackers) are unfamiliar with how the system is designed to work, and therefore do not know what not to do.
That’s why these reward programs exist. Because to successfully offer a bug bounty, a company must have a humble and open mindset. They must acknowledge that they can’t assess their security from every possible angle. Which means that they don’t treat their customers as adversaries. Instead, they treat them as collaborators, as allies who are helping them to improve the business and the experience for the customer.
-
For extra extra credit, open source your software. Though this can take some real guts, many companies are successful at it. Consider Wordpress, arguably one of the most successful pieces of software on the planet, which has been open source since its creation. Being open source, its code is reviewed and audited by hundreds of developers around the world. So not only do they have the chance to identify security issues in the software, but you, as a Wordpress user, can help to highlight them.
Featured photo by by Chris Makarsky - Creative Commons ShareAlike license
