Wouldn’t it be nice if you detect when an external threat actor, who’s taken over one of your users’ endpoints, goes on a poaching expedition through all the information that user has access to on your network?
Easier said than done, right? After all, when malware is running on an endpoint anything it does show up as being performed by that user. How high really are your chances of recognizing those events as being different from the user’s normal behavior? It’s not impossible. Perhaps you are monitoring for failed access attempts on certain folders and perhaps the attacker inadvertently generates a number of such attempts as he masquerades as the hijacked user. But how often do legitimate users accidently trip the same events? And more to the point, where are the files stored. You can monitor failed access attempts on Windows file system. But SharePoint’s audit log has no access failure events because SharePoint never gives you the opportunity to see, much less try to access any object you don’t already have permissions to.
But there is another way to detect information theft attempts that is surprisingly reliable but let me be clear that this method does require some up front preparation and cooperation from end-users and system admins. You’ll only be successful implementing this method if management is serious about detecting late stage information theft attacks by outsiders. That’s another important fact with this technique: it catches outsiders – not insiders who have had the training required to make this strategy work. So here goes.
The idea is to lay traps throughout your unstructured data repositories (i.e. SharePoint document libraries, file shares). These traps are extra folders intermingled among normal folders containing the real information you are trying to protect. Obviously this is non-traditional you’ll need management support if server admins or end-users object. But there’s no real downside to dropping a folder here or there with a naming convention that an informed insider recognizes as a red herring and knows to stay out of. That’s where the end-user training and cooperation comes in. Users who forget and access these red herrings will cause false positives in our monitoring logic.
How does this catch the evil outsider? Well, provided you do your training correctly, an outsider masquerading as one of your users on the network will have no idea that these red herrings exist or what to look for. As they explore your network they will inadvertently stumble on of these red herring folders or libraries and trip the alarm.
Notice that I said “provided you do your training correctly”. For example, you don’t want to post information about “red herring objects, how to recognize them and to avoid accessing them” on your organization intranet or email it to your end users. Better to cover it in onboarding meetings and occasionally when your security officer sits in on department staff meetings. That’s called “out of band” communication and is necessary so that external attackers don’t learn about your red herrings program and thus know to avoid them.
Come up with a naming convention that identifies any red herring folder or document library with a keyword or character sequence. This will be the queue to your users to “stay out”. And you can easily configure your SIEM to tell you whenever it sees any activity involving access to objects with the same watch code. Let’s say the watch code is DA42 and you create a number of folders, document libraries, etc throughout your network with that code in the name. After you create filters for indexers, malware scanners and backup accounts, if you see any such activity – such as Bob accessed “Secret Formulas DA42” you know that either 1) Bob forgot and accesses the red herring or 2) a bad guy running amok on your network.
I’m a real believer in this “active” method of late stage information theft detection. But if it’s too much for you to bite off right now then you need a SIEM with the best possible behavior analysis and anomaly detection. It’s good to use such technology regardless. Checkout EventTracker’s functionality in this area.