A competitor is sending messages to the customer email addresses in the company's Salesforce.com database -- including some dummy addresses set up for testing purposes. Action plan: Use logs and email archives to find out whether an ex-employee stole the data.
When employees have easy access to data, you have to trust them to do the right thing, but you also need ways to verify that they are doing the right thing. That's why I think it's important to invest in things like data leak prevention. We're still tuning our DLP installation, but it nonetheless paid off this week, as did something referred to as "honey tokens."
Here's what happened. We use Salesforce.com as the single repository for information about all of our current customers, potential sales opportunities, sales forecasts and more. It's all highly sensitive material and not anything we'd like our competitors to get their hands on.
That's why one of our marketing executives was worried when she called me into her office earlier this week. She had received a marketing email from one of our competitors. The interesting thing about this email was that it was sent to all of the dummy, or "honey token," email accounts that we had set up in Salesforce for testing purposes. The implication was that the email had also gone to all of our legitimate customers and that this competitor somehow had gotten access to the information in our Salesforce deployment.
An Inside Job
We spread the word about this discovery to our sales and marketing management teams, and someone pointed out that a sales representative in one of our largest Latin American offices had recently resigned to take a position at the very competitor that had sent the marketing emails. Could it be that simple? Could this ex-employee have been careless enough to download contacts from Salesforce to use in his new job?
If so, I thought, then he might have been stupid enough to log in from the office before he stopped working for us. I asked our Salesforce administrators to pull the access logs for the past five days. Some quick Excel filtering revealed that, sure enough, this guy had accessed Salesforce at 4 p.m. on his last day of work!
All right, what did he do during this session? Learning that would require detailed log information, which meant opening a support ticket with Salesforce. When we got the logs a few days later, we saw that the sales rep had run several reports to export complete contact information for all of our customers, as well as a list of potential opportunities and sales pipeline data.
I wanted to know more. I had my security analyst pull emails out of the archives. (We have enabled journaling in our Microsoft Exchange corporate email, so that all emails, both sent and received, are captured, even if they were deleted.) Nothing there. However our recently deployed DLP tool does have rules for detecting customer account numbers. Making use of that feature, we found several unencrypted webmails in which the sales rep sent himself .zip files containing all the exported reports. Although we didn't find an email in which those files were sent to our competitor, we did come across one in which he mentioned that he would be "bringing over" his customer portfolio.
At that point, I gathered my evidence and provided it to our legal counsel and human resources department so they could take action.
And next for the security team? I will be meeting with the owners of our other applications to propose the expansion of the use of honey tokens. And this incident is just what I needed for my 2013 budget planning, which will surely include proposals for additional investment in our DLP infrastructure.
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.
Join in the discussions about security!
Read more about security in Computerworld's Security Topic Center.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.