This Insights article introduces you to Honeypots in SSProtect.
SSProtect is a powerful application data protection platform that combines non-intrusive in-place encryption, two-factor authentication, automatic key management, and a two-party consent trust model that minimizes administrative overhead and end-user training. With automatic, seamless collaboration, integrated backup/restore capabilities and secure, deterministic data access reporting, SSProtect brings together a disparate set of techniques into a single framework, allowing you to retain use of existing applications and infrastructure.
What is a Honeypot?
A Honeypot is a resource designed to help manage networks by redirecting attention or providing data gathering opportunities not possible with live production systems. Often used by Administrators to vet unauthorized behavior, when deployed properly they can provide unique insight into dynamics that otherwise remain unnoticed.
Early Adopter Suggestion
During our Early Adopter proceedings, one of our end-users suggested we turn off the Explorer protection indicator for a couple files and send notification when they were accessed. This way, we could determine if and when malicious intruders were present in our network by avoiding those files ourselves. That's a Honeypot, and it's a solid application of our software's presence throughout an Enterprise network of hosts.
So that’s what we did. And now you can use it yourself - choose any file (or create a new, specific file) and mark it for use as a Honeypot, and all indications that it is a protected entity disappear, yet driver-level monitoring is retained.
Inhibiting the Free For All
This has the effect of making stealth operators think twice before enumerating data on SSProtect'ed hosts. On these systems, data theft doesn't achieve any purpose - the decryption keys are distributed and only available through the use of two-factor authentication, so data remains protected. In-use files are confined to the authorized containing application, so reading plaintext data from disk during user access sessions won't work either.
But what about files that are not marked for protection? Not every file is sensitive, thus not every file requires encryption and tight management. Should an attacker then try and open and/or take these files just in case, due to oversight, intellectual property secrets are temporarily available through human error? Though some systems are integrated with backend workflow management tools and file management solutions, others are managed manually. Why not take all of the unprotected content? Nobody's perfect, and we're all familiar with the risk brought on by human error in secured settings.
But in this case, the answer is simple: One of those unmanaged files might be a trap. Try and copy the file, and the data owner gets notified that his or her Honeypot has been accessed. This makes him or her immediately aware that something is wrong, because everyone, "in the know" avoids opening these datafiles. How much more data will the attacker be able to take before he/she is flushed out? Without question, less than if the notification wasn't there.
Obfuscating Honeypot Configuration
But then surely it’s possible to look into the configuration to determine which files to avoid, right? Not so – host configuration files are protected such that this information is not exposed in plaintext, and wouldn’t it be interesting if the unexpected access of the configuration data itself acted in the same fashion, triggering alarms for the owner?
Even if able to watch the configuration UI while you make changes to your configuration won't help. Honeypot configuration requires that the you enter and utilize independent credentials to enable and expose Honeypot configuration UI elements. This means a typical session that’s not specific to Honeypot configuration will not show those files – or even present Honeypot configuration specifics. Thus if the system is provisioned properly and Honeypot configuration set early-on, the attacker will not have had any chance to observe the configuration. Honeypot designations are thus unknown.
This has the effect of helping to mitigate the risks associated with oversight by users that rely on manual protection of sensitive data. This minimizes the readiness of an attacker who relies on stealth to shamelessly encrypt, archive, and offload anything and everything. Stepping on an electronic landmine would end the party. This is effective at inhibiting forward progress.
But take note: There are those who would tell you that such operators don't care if they are discovered, that they come in, "loud and proud". While there is some truth to that in some situations, it certainly doesn't apply to all and it's most definitely a tactic exploited when people are fooled into believing an attacker disappears once discovered. That is not entirely the case - and in fact, a lot of times that's when, "the big guns" are brought out, and when the attacker starts to use more advanced tools to cover his tracks. A good portion of the responder community believes the attack is over.
It is not.
Give it a Try
We’re excited to be adding this to our protective suite, which we know when applied in total to be an extremely effective solution even for those with the most stringent protection requirements. We welcome you to join us in discussion about your needs and to try out the software. For direct information on how to use this feature, visit our support page on the topic.
Also, if you believe you are the victim of a stealth attacker but cannot prove it with your existing systems and/or budget, give us a call and we’ll get you setup right away, at no cost, and work with you to determine if in fact you have good cause to take further action. With a small amount of effort, a threatening dynamic can often be quickly detected and remediation measures put into play.
Critical Note About Incident Response
One last thing – if you deploy SSProtect and discover that your Honeypot has been triggered and you are in fact being, "cased" by an attacker, do not take action without first consulting an experienced incident response professional. Though the first inclination is to disconnect the machine and/or try and cut off the attacker, that is almost never the best first move. If you don’t have an experienced practitioner available, give us a call and one of our team members can work to help you through many of the challenges that lie ahead, then connect you with the proper partner to help manage your ongoing needs.
This article was published January 29th, 2016