RE: FW: Honeytokens and detection

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

Hi,

Sure if the honeytoken was to be used for internal policy enforcement it
should absolutely be on the secretive side of things. However, I am still
unclear about why ALL the tokens must be a secret to work for Internet
collaborative enforcement?  What if they were public but rotated every month
with new ones?  Would we be weeding out a good number of bad eggs who are up
to no good and the few really clever ones who cross all their t's and dot
their i's will be moving stuff with SCP and therefore not necessarily within
our target anyways?

So if all the major (A)DSL and Cable Modem providers used an IDS to drop and
log any data stream containing the signature from one of 50 or even 500
honeytokens and they shared this signature with each other and a consortium
of other network owners, changing the sigs and honeytokens every month,
wouldn't this be beneficial for enhancing policy management?

Again, I know it's not a simple task to set up and get people to sign up but
the technology and capability is there now.  As Frank Knobbe says, this is
where intrusion detection blurs with forensics.  It's a really interesting
concept.

Sincerely,
-pete.

Pete Herzog
Managing Director
Institute for Security and Open Methodologies
www.isecom.org
www.osstmm.org

ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM
Professional Security Analyst (OPSA) certification authority.  Certifying
professional, practial, and efficient security testing and analysis.


> -----Original Message-----
> From: Jimi Thompson [mailto:jimit () myrealbox com]
> Sent: Saturday, April 26, 2003 1:58 AM
> To: lists () isecom org; FOCUS-IDS () securityfocus com
> Subject: Re: FW: Honeytokens and detection
>
>
> My experience with most "security incidents" is that they are
> insiders - either disgruntled current employees or ex-employees who
> are targeting a specific system or piece of information.  Stastically
> speaking this is fairly standard.  The email about the executive
> bonuses at American Airlines pops immediately to mind.  Other
> examples are the employee who just wants to trash the database/email
> system/hr application server/phone system because they are angry.
> The moral of the story is that you have to trust who you hire even
> when you have to fire them.  Your honeytokens are going to do a bit
> of good in those circumstances.  They aren't going to go after an
> account of someone they've never heard of (i.e. your honeytoken).
> They are going to try to crack the HR VP's/CEO/other person they
> know's account that will have the rights to the thing they want or
> want to destroy.
>
> While external intrusions to run a very close second to "inside
> jobs", inside jobs still have the lead.   Should you stop using them?
> No, but you should be aware of their limitations.
>
> About the sharing thing - the more people who know about it, the less
> likely it is to remain a secret.  Secrecy and the number of people
> who know are inversely proportional.    By the time you have
> replicated this out to your top 3 suppliers and the have replicated
> it out to their top 3 suppliers, you may as well have released it on
> the Internet.
>
>
>
> At 7:02 PM +0200 4/24/03, Pete Herzog wrote:
> > 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
>
>
> --
> Thanks,
>
> Ms. Jimi Thompson, CISSP, Rev.
>
> "I'm a great believer in luck, and I find the harder I work, the more
> I have of it." -- Thomas Jefferson


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