Some security weaknesses can’t be found with a scan or a vulnerability assessment of the infrastructure. As a security manager, you have to keep your eyes open for things that aren’t as secure as they should be, based on any evidence that comes your way. That happened to me a few weeks ago, in just about the best way possible. We were able to take steps to tighten security in a particular area after an incident that could have been damaging but actually wasn’t. I wish all our security lessons could be so benign.
Here’s the story.
Someone called our customer support team saying he was a vice president at a company that’s a customer for our services. He needed a password reset. He told the customer support rep that the password reset function wasn’t sending a new password notification to his email address as he had requested. Our support rep went ahead and changed the password, told the caller the new password and set the password to be changed upon login.
I didn’t know anything about this interaction until later. If I had, I would have protested that the rep needed to verify the vice president’s identity. And as it turns out, we soon learned that the caller was not who he had claimed to be. This came to light a couple of days later when that same vice president called, complaining that he couldn’t log into the application. “Are you using the new password that you set up a couple of days ago?” asked the support rep. “I didn’t change my password a couple of days ago,” was the response. “I just got back from vacation. A couple of days ago, I was on a plane.”
That’s when I got pulled in.
When we looked into the situation, we discovered that the person who had asked for a new password was an employee at the company who reported to the VP. He needed access to some application functionality that’s available only to that VP. Not wanting to bother the VP while he was on vacation, he called, using the VP’s name, in an attempt to get access to his account. It worked, but as far as I’m concerned, it shouldn’t have.
We didn’t get burned, but I did feel some heat. If the unauthorized employee could get the VP’s password with such ease, why couldn’t a true outsider, someone with less than benevolent intentions, do the same thing? We needed to tighten our policies on customer validation.
There are any number of ways to do this, and we’ve all experienced them when calling a financial institution or healthcare provider. You might be asked for the last four digits of your Social Security number, your date of birth, your mother’s maiden name and so on.
With that sort of thing in mind, I met with some of our customer support staff, who told me that most customer service personnel simply asked for the customer’s name and then checked to see if it was listed in Salesforce, just taking the caller’s word that he or she was indeed the user whose name was listed. Some said they might balk if the user’s voice didn’t sound familiar. Naturally, I didn’t find these to be valid methods of verification.
My next step was to review our policy, processes and training documents, and I found them sorely lacking in guidance on positively identifying customers. So I got together with customer support management, and we quickly drafted policy and protocol, the essence of which was that customer support personnel would need to validate users from information not readily available from public sources such as the Internet.
To introduce the new policy and guidance, I put together a presentation for the support staff, in which I demonstrated how easy it is to obtain information from the Internet. I chose one of our largest customers, and with nothing more than a Google search, I identified the most appropriate administrator or power user for our application. I then used LinkedIn to establish that that person was still active at the company. Several other business-oriented sites gave me additional information on the person. In less than two minutes, I had a name, email address, business phone, email and office address. To that I was able to add some interesting personal information from his wide-open Facebook profile. The customer service representatives were stunned, and I in turn was amazed that they had no idea that this sort of information could be gleaned from the Internet.
I then explained what constitutes the kind of information that can’t be easily harvested. The first thing to check is that the user’s caller ID matches the phone number registered in Salesforce. Then they need to to ask the user to answer some predefined security questions, such as the maiden name of the user’s mother. They can also ask the user to verify the customer ID number or some information related to a transaction or activity from the recent past. If all else fails, the customer support representative can call back the user at the registered contact number, or send the user a verification message to the email address on file.
Now that we have a basic policy in place, I will be looking into automation that could help with customer verification. There are several products available that assist with streamlining this business process.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.
Click here for more security articles.