RE: Honeytokens and detection

[<Glenn_Everhart () bankone com>]

There are whole bins (1st 6 digits of card numbers) that I think are not
in use. If some of those were publicized, people could generate
their own bogus card numbers in them, and test for those. People
accessing whole lists would get them and trigger alarms, though they
would not be used further, since thieves would recognize them. I don't
believe such numbers could be kept from the "bad guys". Likewise,
numbers that don't pass the Luhn check digit algorithm will quickly
be recognized, but are still useful for alarms.

For catching thieves, numbers in in-use ranges would need to be used
(and allocated by issuers so they don't get used legitimately).
If you wanted to catch thieves other than at the merchant whose
database got broken into, somehow the merchant database needs to
be salted with some numbers that cannot be told apart from legit
ones, except by the issuers. Good idea to make available such things
but the mechanics require some further design.

Glenn Everhart


-----Original Message-----
From: Lance Spitzner [mailto:lance () honeynet org]
Sent: Thursday, April 03, 2003 5:45 PM
To: honeypots () securityfocus com
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




**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under 
applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If 
you received this transmission in error, please immediately contact the sender and destroy the material in its 
entirety, whether in electronic or hard copy format. Thank you
**********************************************************************