Re: Honeytokens and detection

["Jack Whitsitt \(jofny\)" <seclists () violating us>]

Some notes based on recent work I've done...in no particular order, here:

Credit Card Numbers: The number doesn't have to look real in all cases. If 
you're looking at someone rooting through a cc database and getting a 
honeytoken..it's not because they sniffed a password, it's not because 
someone's session got hijacked, it IS probably because someone got access 
to your database in general...in which case, they're probably pulling a 
bunch of data down without looking at it too closely.

Network Vs Host: They really need to be tied together.  If you're going to 
go with honeytokens as a defensive mechanism, you're probably going to 
want to take advantage of the fact that - if done right - they provide an 
alert mechanism with *no false positives*.  You can - almost at will - 
drop the session, redirect the traffic to a honeypot (bait and switch), 
turn on additional logging mechanisms, etc.  Just "alerting" on 
honeytokens doesn't begin to take advantage of them.  Have your honeytoken 
based HIDS system talk to your NIDS or vice-versa.  

The Idea that Honeytokens Have to be False Data: Incorrect. One of the 
things that I'm currently implementing involves two entities connected via 
a DMZ.  There is certain data from one network that should never, ever, 
cross the DMZ into the other network and vice versa. We see this in tcp/ip 
with internal ip rangers trying to pass through your firewall from 
outside...the same idea is often applicable to data.  Its not just what 
the data is, but where it is. If I see these documents or data tokens 
start to cross, I redirect to a honeypot because its a clear policy 
violation...

Additional thoughts: Some industries are more suited to this than others. 
The medical field (HIPAA), banks, the engery industry, legal, government, 
etc. all tend to have extremely well defined (or should have in some 
cases) information usage protocols.

If I see something cleartext that contains (as Drew suggested in an 
earlier post) a CC# - that can be considered a honeytoken and can be acted 
on.  If I see 32 different login attempts to a medical database in 20 
seconds from the same workstation, thats a honeytoken.

What I'm getting at is that the area I really see Honeytokens being really 
useful in is the domain of "Policy Enforcement" - monitoring information 
manipulation in the context of defined policies...  This may seem like an 
obvious point, but it really opens up some areas of information security 
that are really not addressed well by HIDS, NIDS, and other alerting 
mechanisms that aren't quite as suited for behavior policy enforcement as 
they are technical intrusion monitoring.

-jofny