Re: Honeytokens and detection

["andre" <andreq () infolink com br>]

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

If he manually copies the tablespace files, or uses a named pipe to connect
locally to the database,yes. But if the database is running only in tcp
mode, it would be possibly to put a ids running on the very self database
machine (ok,that would be a little too suspicious).

I already considered this ids signature ideia a few months ago,when the
tokentalk first came up, but couldnt find a suitable way to handle its
exceptions. Anyway a dedicated ids only in front of the database server or
gateway would be my choice. I wonder the possibility of tapping into the
named pipe also...

> > I think that relying on network traffic is the wrong way to handle
> > this.  I suggest having hooks set up on the host itself that monitor
> > when the "token" is opened, read, modified, etc.  In effect, real-time
> > file integrity checking/tripwire on the fly.  With a bit of work the
> > integrity checking could be hidden from all the users on the system and
> > alerts could be sent covertly off of the host.

The only way i see about this is running a hacked version of the database,
which watches for selects (like extending trigger functionality for working
with selects also). It would be a suitable solution if you had something
like:
table 1:   id int, name varchar , (not any really important data...)

table 2: id (foreign key of table 1), social security number, credit card
number, (really secret data)...

Then there would be no false positives, the application would list all the
records in table 1, if the user gets interested in getting confidential
information from , lets say... George W Bush or JFK (who would be our
honeytoken), he would select ONLY the honeytoken id from table2,triggering
our trap.

Still no easy way out. Imagine hacking a commercial database such as db2 or
oracle...