Instead of passively waiting for an intruder to trigger a trap you set, consider adding a truly proactive component to your SIEM strategy.
Aren’t IDS and Log Collectors great? Not so long ago, the problem that most security professionals had was a lack of information. Not any more! Now, many of us have more information than you can throw SQL queries at.
But before we get too excited, let’s get back to reality. Most likely, you have far more information than you need, and sadly, more data than you could possibly ever make sense of.
Isn’t SIEM great? It can take all of that information and correlate it. It correlates it with Vulnerability Assessment Reports, with Asset Management Inventories, with IDS Sensors and Event Logs.
It correlates it like a little kid though, or rather like an idiot savant child. But that’s good enough to fulfill compliance and regulation (and obtain that almighty tick in the check box) and it’s good enough to catch other child-like minds. It is also smart enough to identify malware infections and automated assessments. And that is sadly, all marketing and studies of vendors aside, roughly where it ends.
While these are threats that should be taken seriously, they were not that difficult to spot before, nor do they represent the gravest danger to you and your all-important data (or IP, secrets, or skeletons in the closet, depending on your line of business and persuasion).
But a dedicated, skilled, experienced or even just a patient attacker will go under like a needle in a haystack. Having compromised a host using a targeted spear phishing attack, the wily attacker will wait and bide his time, sniffing traffic, capturing further passwords, probing one packet at a time per hour, per day, per month, or whatever other arbitrary interval fools most IDS systems’ feeble memory. APTs and insidious malware like Stuxnet or Duqu will pass under your expensively, carefully constructed security radar system like a next generation stealth bomber, with similar potential for destruction and collateral damage.
So How do you Find a Needle in a Haystack?
You use a magnet!
The problem with most IDS and SIEM deployments is that they are passive. They wait for an incident to occur, in the hope that their logic is clever enough to detect it in progress. Their ability to recognize and identify malicious events, however, is limited. We like to talk about “naive” signatures, but that description can be applied to signature and rule based approaches in general. Like a naïve child can be amused with sleight of hand tricks, SIEM solutions too can be fooled and evaded. The techniques are well documented and widely disseminated, on both sides of the security fence, and as a consequence are seen in the wild practiced by anyone above script kiddie level.
Barring a huge warp jump forward in artificial intelligence, signature and rule based approaches are as good as it will get though, and we have to work with what we have, not what we’d like.
Time to revisit the humble, under appreciated Honey pot. A Honey pot is a purposefully vulnerable host, designed to attract an attacker with the intent of monitoring him; essentially a fake. Long derided as a mere toy for security researchers and hackers, their primary practical application is found in the anti-malware industry to garner and harvest samples.
The practical reason is quite obvious; they too are looking for a needle in a haystack, trying to obtain samples from and monitor malicious activity on the largest network on the planet: The Internet.
It really is a matter of scale and complexity. Above a certain size of network, be this nodes, users or activity, simple event monitoring can be difficult due to the noise generated by legitimate traffic and false positives, due to the diversity and quantity of observed legitimate behavior, and because of the increasing initial investment and running costs of monitoring complex environments efficiently. All of this is exasperated by the child-like (would monkey-like be too harsh?) naivety of current SIEM solutions, and by the requirements of Business.
To use another analogy, rather than searching for a needle in the haystack, a security incident can be seen as a ball of string. To be able to unravel this ball, you require either the beginning or the end. Due to the complexities mentioned above, the event is often traced from the end of the string. After the act then, where a solution meant to act as a proactive measure to prevent and identify security incidents in progress turns into a forensic tool. Basically, too late.
A honey pot gives you the beginning, or at least the middle of the string, because any activity on a honey pot can and should be considered SUSPICIOUS. You know when it is not used.
You know that no legitimate user or activity is to be expected there. No troublesome noise or pesky users to pollute the information quality.
If you then feed the information from these traps into a SIEM engine, you can correlate the source address(es) with other, otherwise benign looking activity.
You begin unraveling the string ball before it becomes so knotted you need scissors.
Much like most any tool, if used incorrectly or for the wrong task, a honey pot is next to useless, but used as a component of a layered SIEM Monitoring approach, it will provide far better value for money than your IDS sensors.
Attracting Bears…
The honey pot need not be complex or sophisticated.
• It should not be obviously open to compromise (remember, you are after the sneaky attackers, not the ones that rely on luck), but should rather look like a host where patching has been forgotten for a cycle, or has a slight misconfiguration.
• It should blend into its surroundings, if not in identity then at least in characters. A file server on a client network seems realistic; A UNIX mainframe may cause suspicion.
• It should not contain any real sensitive data (but look tantalizing it may make the honey stickier), nor should it provide further access to any other services or hosts.
• Preferably the infiltrator should only have a limited user role, to force privilege escalation attempts to generate more activity. But limiting most functionality will alert a skilled intruder, or at the least make him cautious.
There really is only one primary requirement that has to be met. It needs to log any activity back to a log collector that feeds back to the SIEM engine.
Virtual Machines are a great, inexpensive method of deploying a large number of nodes, running some old Windows XP licenses you have lying around, or Linux. Alternatively, to cover multiple networks centrally, you can multi home a Honey Pot. IPtables for example, the standard firewall included in Linux, allows for extensive logging, and Linux generally supports remote logging with only a few simple tweaks.
Remember, these machines are not intended for serious research or malware analysis (although there is nothing ruling out a dual role). They are meant to attract careful and cautious intruders by looking vulnerable and attractive, and thus do not need anywhere near the same amount of customization or hidden security. You want to identify attackers and compromised nodes.
Not to be mistaken with a Darknet, an empty but monitored network (“Dark”, as in no lights on), designed to detect port scans and similar network probes, our Honey Pot has to feel and look like the real McCoy. We want to fool our opponent, and lure him into a careless move so he gives away his presence.
Unless an attacker knows precisely what he is after and where (in which case there are other, more suitable approaches, but that is for another article…), he will inevitably attempt to escalate privileges, reinforce and secure his access or search and gain access to pay data. In a best case and most likely scenario, an intruding entity will need to infiltrate the target network deeper to achieve its ultimate aims, and it is here we are attempting to force him into a move that will give him away, even if he is cautious and wily.
That way instead of passively waiting for an intruder to trigger a trap, you are setting it, adding a truly proactive component to your SIEM strategy. Then you just need to sit back, and listen carefully for the “ping”. It’s not a packet’s TTL being incremented. It’s the needle hitting the magnet.
