Site hacking is a case of ‘when’ not ‘if’
Virtually everyone in IT (or maybe the highly developed world) knows about identity theft and we’re all pretty much aware that talk is no longer about ‘if’ a site or system get hacked, but rather ‘when’ it gets hacked. In spite of this, organizations still store more data than is absolutely necessary.
With all the reading and observation I do as a service management industry professional, I sometimes find myself amazed at the amount of data now requested or retained when doing business via the web or even directly with retail brick and mortar stores.
Before I begin, PHI relates to personal health information, while PII is personal identifying information, generally in a combination that could make it easier to steal your identity in the hands of the wrong people. This blog addresses PII, but when you take action on it, you might also consider PHI, ensuring only HR has access to this information and that it is encrypted or otherwise secured.
Returning to the blog, two recent shopping ventures come to mind:
(1) Recently I attempted to purchase tickets via one of the most well known on-line ticket brokers in the country, because the event’s website directed all sales via that site. After selecting my seats, I had to create an account to check out. The website then required my address, phone number, credit card (obviously) and BIRTHDAY including the year. This was a required field. I could not understand why my full birthday was needed to buy show tickets, as it seemed to me that providing my birthday along with my address and credit card was getting awfully close to PII where a website breach could expose me to identity theft. As I left the site to go call the theater directly I was left wondering why IT had allowed this to happen. It cost the company revenue when I purchased my tickets by calling the box office.
(2) My visit to a local jewelry store, who has my birthday (no year) on file as they send birthday discounts via email annually. This was fine by me, given they only had my email address and birthday. When they asked for my home address however, I started to ask what information they retain on file, and what they would use if for and then politely declined. I gave them a choice of birthday or home address and we landed on birthday.
These two events come on the heels of last year’s credit card disasters suffered by Target and Home Depot, along with countless other credit card and bank breaches that have become common. And yes, I almost forgot the health insurance processing company breach that just resulted in a free year of credit protection to everyone who works in my organization.
So what can IT do to help?
IT can begin by helping their organization strengthen both their internal and external processes and systems:
(1) Check out the options on charge sales: Point of Sale systems used by large retailers often store credit card information along with the transaction number. This enables the store to credit a person’s card without asking them for the physical card, but it also means they are storing a large amount of credit card data. Is this really necessary? I’d rather have to provide the card used for the purchase than to have my card’s information in their system. This is likely the sort of practice that led to the Target and Home Depot breaches. IT organizations need to begin to shift the industry away from storing this data. At the very least it should be purged after the refund period has passed.
(2) Leverage payment services on websites: Consider adding payment options that include PayPal and other consolidated payment services to web site checkout options. If customers use PayPal or a similar service for ALL web payments, their credit card information is on only one payment system vs. twenty or thirty. On a personal level, consider doing this to reduce your own exposure.
(3) Audit customer data collected: IT should immediately perform an audit of all CRM systems and other systems that collect data about customers to see if there is PII exposure. In addition to eliminating any data that is not absolutely required (like the year on a birth date) encryption should be added at the very least. Additionally, that encryption should be in place internally for all data that a person’s role does not need to support the customer. Billing systems are trickier as they do require credit card number and addresses. Care should be taken to remove birthdates from these systems as the combination of the three data points moves into that PII situation. Internally, an audit should be performed for both PII and PHI data being collected from employees, ensuring it is properly secured or eliminated. If HR case management systems are in use this can get sticky. Data should be encrypted so ONLY HR can see it and HR should be trained to redact any information supplied by a customer (through self service) that reveals health or leave information.
(4) Conduct an education program: Begin educating the non-technical people in the organization. Train them in being security conscious and teach them what to look for. After all, you know what they say: ‘an ounce of prevention…’
While there will always be hackers trying to break in, let’s begin fighting back to the best of our abilities!
