|
|||||||||||
|
RE: Honeytokens and detection
From: Grant, Liam <Liam.Grant(at)GDC4S.Com>
Date: Fri Apr 04 2003 - 10:12:37 EST
The Social Security Administration (not IRS) has provided some information along those lines (googling for 'invalid "social security numbers"'): http://policy.ssa.gov/poms.nsf/36f3b2ee954f0075852568c100630558/ed1c5274f1bc 8a9f85256ce2006a1858?OpenDocument To summarize, numbers beginning 666-xx-xxxx have not and will not be assigned. 8xx-xx-xxxx and 9xx-xx-xxxx have not yet been assigned. As of late 2000, they were up to 765-xx-xxxx. I'm sure there is more up-to-date info there, but that's the quick look. I'm also sure that if you use 123-45-6789, you won't be using someone else's number either. VISA and MasterCard probably have some public numbers that are for testing purposes only (just so a test that gets through to them doesn't charge someone's number). One problem I see with the whole concept is that if I was the other side, I'd be using an encrypted tunnel to grab the info. It's a good concept for catching the inexperienced outsider, or the trusted insider (less likely to bother encrypting, trusting in his authorized access to the data), but limited in it's application in many ways. As with anything else though, every extra step helps, and it's cheap. --
-----Original Message-----
I've been playing with the concept of Honeytokens, thinking of ways that they could apply to intrusion detection. Based on recent events, had some ideas. There have been reports of databases broken into, with thousands of social security numbers or millions of credit cards stolen. One of the problems is in some of these cases, it was not known for days, weeks, or even months that the data had been compromised. I was thinking that Honeytokes could be used for detecting when such data was compromised/stolen. Inside each database Honeytoken numbers are inserted. These tokens are known to have no value, no one should be using them. Detection mechanisms such as IDS signatures are then created to look for and detect these tokens being access or used. If these tokens are seen, this means someone has captured the database, or looking where they shouldn't be. For example, create bogus social security numbers and store them in your SSN database. If the honeytoken SSN's hit your network, someone may have just grabbed your database. For a CC database, insert honeytoken CC's and monitor for those to hit your wire. Once again, if you see someone retrieving these numbers, someone is most likely being naughty. The advantage with this detection method is its both very simple and should dramatically reduce false positives. What would be even better is if the IRS or some credit card companies could post or distribute such honeytoken numbers, so we within the security community are certain we are not implanting valid numbers. Either way, a thought to consider :) --
ALERT: Exploiting Web Applications- A Step-by-Step Attack Analysis Learn why 70% of today's successful hacks involve Web Application attacks such as: SQL Injection, XSS, Cookie Manipulation and Parameter Manipulation. http://www.spidynamics.com/mktg/webappsecurity71 ALERT: Exploiting Web Applications- A Step-by-Step Attack Analysis Learn why 70% of today's successful hacks involve Web Application attacks such as: SQL Injection, XSS, Cookie Manipulation and Parameter Manipulation. http://www.spidynamics.com/mktg/webappsecurity71 Received on Fri Apr 4 15:32:55 2003 This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:01:11 EDT |
||||||||||
|
|||||||||||