This blog is based on a true story – names have been changed to protect the innocent.
Late one Friday afternoon Nigel, a Senior Executive, gets a panicked phone call from the Head of Customer Services, Steve. Steve says one of his regular customers is on the phone claiming Steve’s company are the source of a breach that has led to his credit card details being fraudulently used. The customer is irate and is threatening to take his story to the press and to social media if he doesn’t get a satisfactory response within 24 hours. Not only does Steve want to retain the customer, he’s concerned about the potential damage to the company’s reputation if this customer does take action.
At first, Nigel feels confident that it wouldn’t be them – they spent a huge sum of money last year improving their ‘security software’. He confidently picks up the phone and calls Dave, their Head of IT, to ask him to take a closer look. Dave knew that in the past, the sales team used to write down customer credit card details onto the order forms, which they would then store in a shared drive. Sometimes they were scanned in and sometimes they were typed directly into the Word document. They manually moved a batch of these a while back and explained to the sales team not do this in the future. They urged them to use the authorised systems and then also sent them all a ‘Data Security Policy’ handbook to read.
Given what Dave knows, there is a possibility the customer complaint could be valid, so he sets to work to come up with a response. He now has 23 hours to report back to Nigel with as much information as he can find as to what’s happened. He finds the initial credit card transaction on the authorized transactions list, which is fine. He can see the time and date of the transaction, which gives him his starting point, but he needs to get deeper. Of the many questions he needs to answer, here are 7 that really mattered:
- Are there any other instances of this customer’s credit card on any other servers within their unstructured data in their organization today (or since It was first seen)?
- Who really created/authored the file(s)?
- Who else has been accessing this file and what were they doing with it? Has it been copied, moved, modified, deleted, accessed?
- Are there any significant trends that could be considered suspicious with regards to how employees have interacted with this file?
- Who currently has which levels of access to this file and who has had access since the file was created?
- Have any of the permissions been changed?
- How was access granted to this file and when was it granted?
He attempted to resolve some of the answers using Event Log Viewer but ultimately couldn’t really get anything that categorically gave him the answers he needed as the logs were inconsistent and hard to decipher. He resorted to talking directly with the sales team and managed to establish that one the Sales Administrators, Julie, didn’t get the memo about ‘Card Handling Best Practices’ and was still storing credit card details on the order forms. She regularly copied these order forms into a ‘Sales Admin’ folder – a shared drive where she kept all her customer order forms. This was an open share (as she only worked part time) and she put her documents in this folder to allow her colleagues in both Accounts and Admin to access them when she was out of the office. So, not only does Dave have the issue of one potential credit card breach, he now has a whole new set of challenges he needs to address and resolve. Namely:
- What else does this user have access to?
- Is anyone else doing the same thing?
- What other files has this user copied and to where?
- Was it appropriate this person had access to this file/folder to do her job?
- How was the issue not spotted before if got reported by a customer?
Trying to answer such questions without a purpose-built security platform was just not workable. Dave was faced with 12 questions he simply wasn’t able to answer. What’s worse, Dave had been aware he had this ‘auditing’ gap for a while. He identified this as an issue the last time they did an audit and looked at a few products. They didn’t go ahead with the project because the options were far too expensive to justify and would have a been a huge task to implement. Given that a year ago they spent a large amount of money on state of the art firewalls, trying to justify further spend was simply too difficult. In the minds of the higher-ups, they had never had this issue before so why do they need to spend money trying to fix a problem they don’t even know they have?
Had Dave have implemented Lepide Data Security Platform, he could have likely kept it well within budget and had the capability to answer these questions with very little work. More importantly, he could have put in place alerts and scheduled reports to ensure he would have known instantly what was happening with regards to user behaviour around sensitive data, around access rights and over the systems that facilitate access. Perhaps Dave might have gotten his weekend back!