RE: Honeytokens and detection

["Grant, Liam" <Liam.Grant () GDC4S Com>]

Lance,

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.

--
Liam Grant, CISSP



-----Original Message-----
From: Lance Spitzner [mailto:lance () honeynet org]
Sent: Thursday, April 03, 2003 5:45 PM
To: Focus on Intrusion Detection Systems
Subject: Honeytokens and detection


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 :)

-- 
Lance Spitzner
http://www.tracking-hackers.com


-----------------------------------------------------------
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