FW: Honeytokens and detection

["Pete Herzog" <lists () isecom org>]

Sorry for the delay; I thought about this for a while.

While it may be necessary to use internally generated honeytokens to keep
them extra secret (TM) what if these were updated every so often?  What if
they were changed and distributed through a trusted network (partners who
share policy on what to do if the token shows up on their radar screen) with
say common IDS sigs in both compressed and standard forms?  What if after 3
months, these sigs were then released in the wild for anyone to update and
help track (an expanded partner network).

I see the use here for both the common ones (like the eicar test script for
AV) and home spun ones.  Even some who "call home" somehow.  A heterogeneous
mix would ensure viability of the honeytokens but only large collaboration
would make it worthwhile to use over the Internet.

Of course I also see tremendous privacy violation possibilities in this
technology.  Doubleclick meets Honeytoken meets RIAA meets DMCA anyone?  One
ring to bind them....  Scary stuff.  I'd rather we begin collaborative work
on this first and expand the knowledge and use as we come to terms with the
ethics.
Sincerely,
-pete.
Pete Herzog
Managing Director ISECOM
www.isecom.org
www.osstmm.org


-----Original Message-----
From: AQBARROS () BKB com br [mailto:AQBARROS () BKB com br]
Sent: Tuesday, April 15, 2003 7:29 PM
To: fknobbe () knobbeits com; lists () isecom org
Cc: david () zbonski com; lance () honeynet org; FOCUS-IDS () securityfocus com
Subject: RES: Honeytokens and detection


I think that we cannot forget that honeytokens were already here for a long
time, and that they aren't the final solution for tracking malicious
activity. They are just one more tool. A tool that has serious limitations
when we deal with encryption and compression.
As for the fake administrator, you can use it as a real valid user, with a
random password with maximum size. Whenever you detect someone trying to use
it (you can do it detecting the traffic or watching logs), the alarm rings.
I see honeytokens, as well as honeypots, being used as part of a intrusion
detection and prevention strategy. It's wise to not overestimate its
possibilities.
Regards,
Augusto.
-----Mensagem original-----
De: Frank Knobbe [mailto:fknobbe () knobbeits com]
Enviada em: segunda-feira, 14 de abril de 2003 0:07
Para: lists () isecom org
Cc: david () zbonski com; lance () honeynet org; FOCUS-IDS () securityfocus com
Assunto: RE: Honeytokens and detection


On Tue, 2003-04-08 at 15:57, Pete Herzog wrote:
> I disagree.  I think you may not get the illustration in full.  If the
bogus
> CCs or ID numbers were known and padded into excel sheets, particular DBs,
> etc., especially those with thousands of numbers, the thief would be
> downloading the whole thing at once.  It would not be about downloading
only
> part of the DB or part of an Excel sheet as long as the dangerous ones
don't
> get downloaded.
>
> Since it's downloaded in bulk, the IDS will look for that token somewhere
in
> the download (or upload).  [...]


Pete,
I almost agreed with you, but then I started to think about some
scenarios.
a) Someone breaks into the database server. He pokes around and looks at
a few records (most likely unencrypted).
b) Someone breaks into the database server. Since the database is very
large, he only samples the top 100 rows of data so he can retrieve a few
numbers to buy himself a new watchamacallit. It's debatable if he could
choose to encrypt the transfer, although chances are better.
c) Someone breaks into the database server. Circumstances (size,
bandwidth, time) are favorable to download the whole database. If the
attacker does not encrypt the transfer, he would most likely compress
the data.


So, if data is bulk harvested, partially or in full, both encryption and
compression would render the honeytokens useless. Casual snooping would
have a higher probability to occur in clear text, but less of a chance
to hit a honey token.
I'm wondering how useful the honeytokens really are for a) professional
thieves (encryption) and b) large datasets (high miss/hit ratio).
Note that we are only talking about detection of data in transit, not of
detection of data in use (as would be the case with copy-bugs etc....
you know, those intentional typos in documents to mark them).


Augusto's reference to the fake administrator/root account would
probably fall into the 'detect on use' category, not into the 'detect in
transit' category. (i.e. administrator account in network packet)
Perhaps we need to define classification structure of honeytokens. Your
thoughts?
Regards,
Frank





Esta mensagem, incluindo seus anexos, pode conter informação confidencial
e/ou privilegiada. Se você recebeu este e-mail por engano, não utilize,
copie ou divulgue as informações nele contidas. E, por favor, avise
imediatamente o remetente, respondendo ao e-mail, e em seguida apague-o.
Este e-mail possui conteúdo informativo e não transacional. Caso necessite
de atendimento imediato, recomendamos utilizar um dos canais disponíveis:
Internet Banking , BankBoston por telefone ou agência/representante de
atendimento de sua conveniência. Agradecemos sua colaboração.
This message, including its attachments, may contain confidential and/or
privileged information. If you received this email by mistake, do not use,
copy or disseminate any information herein contained. Please notify us
immediately by replying to the sender and then delete it. This email is for
information purposes only, not for transactions. In case you need immediate
assistance, please use one of the following channels: Internet Banking ,
BankBoston by phone or branch/relationship manager at your convenience.
Thank you for your cooperation.


------------------------------------------------------------------------------
INTRUSION PREVENTION: READY FOR PRIME TIME?
 
IntruShield now offers unprecedented Intrusion IntelligenceTM capabilities - 
including intrusion identification, relevancy, direction, impact and analysis - enabling a path to prevention. 
 
Download the latest white paper "Intrusion Prevention: Myths, Challenges, and Requirements" at: 
http://www.securityfocus.com/IntruVert-focus-ids