Slashdot Mirror


Honeytokens: The Other Honeypot

martyros writes "I just read a fascinating article by Lance Spitzner securityfocus.com about a concept he calls honeytokens. The idea is similar to that of a honeypot, which he defines as "an information system resource whose value lies in unauthorized or illicit use of that resource". Rather than having a computer that's designed to be broken into, however, you have say, a record in a database or a file has no legitimate use; ergo, if anyone uses it, it must be illegitimate. An example he gives: adding a record to the hospital database for a guy named "John F. Kennedy". It doesn't correspond to a real person, so no one has any business looking at the file. If someone does access it, you know that they're abusing their privileges somehow. The article has several other clever examples, which I found very thought-provoking."

10 of 427 comments (clear)

  1. Just like "ringers" by vegetablespork · · Score: 5, Informative
    Folks who rent mailing lists add "ringers," which, if they receive a mailing after the term of the rental is up, yield prima facie evidence of violation of the rental contract.

    This is an interesting use of a known technique to help detect the unauthorized use of data, and alert administrators that the barn door is open--and maybe even who opened it.

    --

    Call (206) 338-5780 COLLECT for information about a genuine BA, BS, MA, MS, MBA, or Ph.D.

  2. The problem... by melete · · Score: 5, Insightful


    The problem with this (and with a lesser degree, with honeypots) is that these tokens will get accessed in legitimate ways -- for example, what if your secretarial staff is creating a mailing list, and "JFK" gets sent something? Or you have a browse function in an application that uses the database?

    It's a good idea, but not a panacea.

  3. Re:Or they made a mistake by in7ane · · Score: 5, Insightful

    I agree, it's just too likely that it will be people from within the organization just 'poking around' with no ill intent.

    It's just human nature - same as having to open a box with the sign 'do not open' on it :)

    Add to this that authorized workers will likely be told about these and told to keep out - causing a flood of 'I wonder what's in there...'

  4. I do this already by L.+VeGas · · Score: 5, Funny

    By placing arsenic in your water bottle that you leave in the refrigerator, you can tell who's been pilfering your lunch.

  5. Been around for awhile by miyako · · Score: 5, Funny

    ...several years in fact, although in a different form.
    A while back a bunch of businesses created a website called slashdot to monitor people who were surfing the net instead of doing work.

    --
    Famous Last Words: "hmm...wikipedia says it's edible"
  6. Re:Or they made a mistake by highcaffeine · · Score: 5, Insightful

    I was going to mod this down (overrated), but decided I'd rather reply.

    No one said that honeytokens are superior in every way to honeypots and should be used in place of the latter. That you pulled out of your hindquarters. Basically, what you said could be expressed similarly in this example: "Seat belts are not absolutely superior in every way to the steel frame of a car, so what's the point in buckling up?"

    I would hope that makes it clear how faulty your logic is. Like using seat belts in addition to a protective steel frame, to provide added protection, honeytokens could be used in addition to honeypots. Their ultimate goals are the same: protect your life (frame/seat belts) or your data (honey[pot|token]). If your life/data is that important, why not provide all the layers of security you can?

    One advantage that honeytokens do have is in who they can help protect against. Honeypots are typically deployed to detect and help figure out how to protect against external threats. Anyone with a shred of sense about security knows, however, that you also need to protect against internal threats. Deploying honeytokens can help in that vein, by posssibly detecting internal abuse of your systems.

    Just because honeytokens won't protect against everything, solve global hunger, and bring about world peace, doesn't mean they shouldn't or can't be used effectively.

  7. Re:Or they made a mistake by aafiske · · Score: 5, Interesting

    "Or they were poking around bored.

    Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right."

    Well, for point one, if someone is bored and is poking around a medical database, that's a problem. And someone using a honeytoken credit card number is never okay. It's not something you do because you're bored.

    And the hacker might have compromised one system and gotten data, but the point is that you put some fake data in there as well. So then hacker says 'hooray, I've gotten the CFO's password, let me go check out some interesting numbers in their computers' and suddenly they're caught red-handed, because that login doesn't exist in reality, and the computer in question is set up to notify people immediately on a honeytoken login.

    These examples are taken from the article. It's a pretty clever idea and is much more versatile than the idea of a honeypot just as a server.

  8. Re:Or they made a mistake by dasmegabyte · · Score: 5, Insightful

    Ok -- I think this isn't necessarily a bad idea, so long as you don't expect it to be the end-all, be-all of security. I often perform wierd ad-hoc queries on tables for data mining purposes, or to help our support team do things that their program just won't do (like cross index reports for a list of ids).

    Some DBAs LOVE to think that their precious data is only access the way they want it to be accessed. I once had a guy tell me, flat out, "You guys should never be doing ad hoc queries. Write and submit a stored procedure for everything you do." I have never heard a more ivory tower asshole statement in my life, and you better believe I didn't listen for a second. Nor should I have, nor would he really want me to...when the CEO comes over and asks for usage statistics for a potential customer, he doesn't want to be told "Wait until the DBA shmuck reviews this query first." It becomes harder to justify your excessive salary when all you do is prevent us programming peons from doing our job and call it "security."

    If I pull up a honeyrecord, and you're my dba, you should ask me about it, but not assume my account has been hacked and lock it down. Which means this is nothing more than yet another check measure. You'll still have to eye your logs and know your system.

    You know, this is actually a great way to prove somebody from outside has been data mining, and prosecute them for it. Put bullshit data in your db. If it shows up on somebody's website as fact, you'll know they were grabbing your shit. Producers of maps do similar things...invent dead end streets and place them where nobody will ever try to go. If you look at somebody else's map, and you find your BS street, you know they plagarized. Just make sure you never buy a house on that street. Heh.

    --
    Hey freaks: now you're ju
  9. Re:Or they made a mistake by wmshub · · Score: 5, Informative

    If you are a desk clerk at a hospital, then the hospital would have every right to fire you.

    Hospital records are supposed to be kept as private as possible. Employees who satisfy their own curiousity without caring whose privacy they compromise should never have be allowed to have jobs where "poking around" in private data is possible.

  10. Re:Popular anti-spam technique by Greedo · · Score: 5, Interesting

    Even better (IMHO) is a system I developed for dynamic pages.

    Each page is seeded with a random, unique email address. Also, that address is stored in a database, along with the time it was generated, the page it was displayed on, and info about the viewer (i.e. IP address, UserAgent, etc.).

    Then, if that email is ever used, another automatic system reads that data out of the database and can correlate it.

    It's interesting to see some things. Like how long after an email is harvested is it being used (as little as 4 hours), and whether the people harvesting are also spamming (usually not). This way, you can fight spam by attacking/blocking the spammers *and* the people doing the harvesting.

    Oh, and I claim prior art ... in case Bezos is reading this.

    --
    Tuus crepidae innexilis sunt.